将Java Flight Recorder与OpenJDK 11结合使用

Java Flight Recorder(JFR)曾经是Oracle JDK的商业附加组件。 由于它是与Java Mission Control一起最近开源的,因此使用OpenJDK 11的每个人现在都可以使用此出色的工具免费对Java应用程序进行故障排除。 JFR以前是专有解决方案,对于那些依赖OpenJDK早期版本的人来说,它可能鲜为人知。 因此,我认为有必要写一篇有关在OpenJDK 11中使用JFR的新文章。

将Java Flight Recorder与OpenJDK 11结合使用_第1张图片

1.概述

关于Java Flight Recorder

JFR是一种分析工具,用于从正在运行的Java应用程序中收集诊断信息和分析数据。 它的性能开销可以忽略不计,通常低于1%。 对于运行时间较短的应用程序,此开销可能会超出该开销,因为JFR在启动时需要一些预热时间。

使用JFR诊断错误的应用程序可能会大大缩短解决时间。 从异常的出现开始就可以看出异常,直到出现异常,直到导致应用程序死机为止。 当然,并非所有问题都那么严重。 JFR收集有关正在运行的线程,GC周期,锁,套接字,内存使用量以及更多内容的数据。

Java Flight Recorder开源

正如我在介绍中提到的那样,该功能曾经是Oracle JDK的专有功能,并且正式地它仅适用于付费的Oracle客户。 实际上,您可以使用-XX:+UnlockCommercialFeatures -XX:+FlightRecorder标志启用它,并且早期的JVM不会强制使用许可证密钥或类似的东西。

甲骨文公司的马克·雷因霍尔德 ( Mark Reinhold)希望更快地推动Java的发展,并从发布周期为六个月的某些Linux操作系统中汲取灵感。 我认为他可能想到过Ubuntu,尽管他没有提及。 但是,从版本9开始的Java SE确实具有可预测的六个月发布周期。

长话短说,为了缩短发布时间,他们现在正在单一代码库上工作,这使得Oracle JDK和OpenJDK构建可以互换。 最终, 从Java 11开始,Oracle在开源GPL和商业许可下提供了JDK版本 。 如果您习惯于免费获取Oracle JDK二进制文件,请下载OpenJDK构建,它们在功能上是相同的。

结果,JFR获得了开源,并通过单一代码库简化了发布过程,从而使OpenJDK对开发人员更具吸引力。

JFR包装差异

使用-XX:+UnlockCommercialFeatures选项时,Oracle JDK 11会发出警告,而OpenJDK无法识别此选项并报告错误。

Java Mission Control也是开源的

JMC是用于打开生产时间性能和JFR产生的诊断记录的客户端工具 。 JMC还提供了其他功能,例如JMX控制台和堆转储分析器。 从7到10的Oracle JDK版本包含JMC,但已将其分离,现在可以单独下载获得 。

JMC最近也已经开源 ,这意味着现在使用OpenJDK 11的任何人都可以使用整个工具集(JFR + JMC)。在撰写本文时,第一个开源JMC版本7尚未发布到GA,但是提供了早期访问版本。

将Java Flight Recorder与OpenJDK 11结合使用_第2张图片

2.使用飞行记录器

我一直没有在生产中连续使用JFR,因为那样会违反Oracle JDK的许可证。 为了发展,一切都可以根据我的最佳知识来使用。 因此,使用Oracle JDK的人们(没有支持合同)最终不得不在其开发机器上本地重现性能问题。

好吧,那么,让我们看一些代码。 这将是对Java Flight Recorder的基础知识的简单演示,我故意给我们一些调试方面的麻烦。

public class OOMEGenerator {

  static BlockingQueue queue = new LinkedBlockingQueue<>();

  public static void main(String[] args) {
    new Thread(new Consumer()).start();
    new Thread(new Producer()).start();
  }

  static class Producer implements Runnable {

    public void run() {
      while (true) {
        queue.offer(new byte[3 * 1024 * 1024]);

        try {
          Thread.sleep(50);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
    }

  }

  static class Consumer implements Runnable {

    public void run() {
      while (true) {
        try {
          queue.take();
          Thread.sleep(100);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
    }

  }

}

为了展示经典的OOME,我们可以将新对象添加到集合中。 我选择了这一模式,因为我经常在生产中看到这种特定模式。 也就是说,有两个(或更多)组件,其中一些产生新的对象,而某些消耗这些对象。 问题源于这样一个事实,即内部缓冲区(组件通过该缓冲区进行通信)的容量可能不受限制。

当我说潜在的无限时,我的意思是缓冲区大小乘以一个平均对象的大小,它是如此之大,一段时间后,它只是吞噬了所有堆空间。 通常可能要花费数小时,数天或一周的时间,但最终会发生OutOfMemoryError

通常,开发人员认为在日志中看到OutOfMemoryError肯定反映了编程错误和内存泄漏。 有时,堆转储分析可以肯定地确认或混淆这一点,但是在某些情况下,它不是黑色还是白色,而您根本无法分辨。 在这些情况下,带有历史数据的JFR成为资源。

启用JFR

我们可以从上面的简短程序中看到一个OutOfMemoryError ,它需要一些时间,但是这将会发生。 使用JFR,我们可以详细了解GC的时间,CPU使用率和许多其他方面的时间过程以及错误的特征。

% java \
    -Xmx1024m \
    -Xlog:gc*=debug:file=gc.log:utctime,uptime,tid,level:filecount=10,filesize=128m \
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof \
    -XX:StartFlightRecording=\
        disk=true, \
        dumponexit=true, \
        filename=recording.jfr, \
        maxsize=1024m,\
        maxage=1d,\
        settings=profile \
        path-to-gc-roots=true \
    OOMEGenerator 

Started recording 1.
Use jcmd 5469 JFR.dump name=1 to copy recording data to file.

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at nl.wizenoze.storm.OOMEGenerator.main(OOMEGenerator.java:12)

22.31s user 3.46s system 24% cpu 1:43.94 total

我在生产中使用这些调试设置。 从这种意义上说,这些JVM参数也为我自己提供了一个注释,当我需要它们时,我会在这里找到它们。

与JFR相关的是突出显示的部分(第5-11行)。 默认情况下,记录的最大大小,最长的期限或记录的数据均不受限制。 我尝试了各种设置,并应用了maxagemaxsize被证明是有用的。 在早期的JDK版本中,JFR曾经具有更多设置,但是在版本11中它们简化了它们。

我想提醒您注意dumponexit选项。 在正常情况下,通常在停止捕获数据时将记录写入磁盘。 当JVM终止时,自然会发生这种情况。 但是,根据我的经验,当终止异常时,例如当堆空间不足时,则记录的大小可能为零字节。 尽管JFR设置的文档尚不清楚, dumponexit有什么区别,但我观察到,应用它对于从有问题的JVM中捕获数据是有利的。

JFR带有两个出厂的配置文件( defaultprofile ),它们定义了应将哪些事件保留到捕获的记录中。 如果未指定设置选项,则使用default配置文件。 在此示例中,我使用了更广泛的配置文件事件定义,还启用了跟踪GC根目录的路径的功能。 这些会给运行中的JVM带来更高的开销,我不建议在生产中使用它们。

按需捕获记录

只要有JVM,就会将性能数据写入磁盘,但是可以在任何给定时间使用JCMD实用程序按需导出记录。 JFR.check命令返回有关当前正在运行的记录的详细信息。

% jcmd PID JFR.check name=1
14647:
Recording 1: name=1 maxsize=1.0GB maxage=1d (running)

除此之外, JFR.dump允许您导出到目前为止已记录的所有内容,而不必等待正在运行的JVM终止或停止记录。

%jcmd 5469 JFR.dump name=1 filename=dump.jfr

JCMD实用程序提供了其他故障排除选项 。

分析JFR录音

如前所述,JMC必须单独下载。 尽管它只是一个早期访问版本,但我发现它完全可用,而没有遇到重大故障。 在JMC 6中,添加了“自动分析结果”屏幕,以帮助工程师更快地诊断问题。 我一直在使用较旧的JMC 5.5版本,发现此版本很有用,并且确实提供了有用的技巧。 它已正确地将OOMEGenerator$Producer标识为正在生成的源或大对象,并且还建议平衡线程之间的分配率。

将Java Flight Recorder与OpenJDK 11结合使用_第3张图片

从内存视图提供堆使用情况的角度来看,它是可以的,但是由于某些原因,对象直方图列表中的数字丢失了。 由于JMC的较旧版本无法打开此录音,因此我不知道该录音的样子。 我认为这可能是一个错误。

将Java Flight Recorder与OpenJDK 11结合使用_第4张图片

看到GC暂停时间以及堆大小分配更改也很有用,但是在较早的JMC版本中,这种情况看起来更好。

将Java Flight Recorder与OpenJDK 11结合使用_第5张图片

3.注意事项

  • JFR记录不向后兼容 – OpenJDK 11产生的记录不向后兼容,并且较旧的JMC版本(尝试5.5和6)不会打开它们
  • JMC 7仍然是早期访问版本 – GA中的功能可能会更改,并且某些错误可能会在这里和那里潜伏。
  • 官方Docker映像中有一个错误 –启用JFR时阻止JVM启动
  • JMC 7无法分析HPROF文件 -尽管OpenJDK的Wiki声明它能够做到这一点

4。结论

Java Flight Recorder(JFR)是一种分析工具,用于从运行的Java应用程序收集诊断信息和分析数据。 它收集有关正在运行的线程,GC周期,锁,套接字,内存使用量以及更多内容的数据。 JFR和Java Mission Control(一种用于分析记录的工具)已经开源,并且不再是Oracle的专有产品。 Oracle的这一举动使OpenJDK对开发人员更具吸引力。

从11版开始,Java Mission Control尚未与JDK捆绑在一起,但可以单独下载获得 。

使用伪应用程序,我们有意生成了OutOfMemoryError ,捕获了堆转储和JFR记录,并使用JMC分析了后者。

JFR和JMC是OpenJDK开源领域中的新事物,而OpenJDK 11在撰写本文时也很新,因此必须经过一段时间才能使这些工具成熟。

翻译自: https://www.javacodegeeks.com/2018/12/using-java-flight-recorder-openjdk-11.html

你可能感兴趣的:(java,大数据,linux,编程语言,python)