recorder_将Java Flight Recorder与OpenJDK 11一起使用

recorder

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

1.概述

关于Java Flight Recorder

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

使用JFR诊断错误的应用程序可能会大大缩短解决时间。 异常从出现的最初就可以看出，随着它的发展，最终直到导致应用程序崩溃的那一点。 当然，并非所有问题都那么严重。 JFR收集有关正在运行的线程，GC周期，锁，套接字，内存使用量以及更多内容的数据。

Java Flight Recorder开源

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

Oracle公司的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，但是提供了早期访问版本。

2.使用飞行记录器

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

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

public class OOMEGenerator {

  static BlockingQueue<byte[]> 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行）。 默认情况下，记录的最大大小，最长的期限或记录的数据均不受限制。 我尝试了各种设置，并应用了maxage和maxsize被证明是有用的。 在早期的JDK版本中，JFR曾经具有更多设置，但是在版本11中它们简化了它们。

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

JFR带有两个出厂的配置文件（ default和profile ），它们定义了应将哪些事件保留到捕获的记录中。 如果未指定设置选项，则使用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标识为正在生成的源或大对象，并且还建议平衡线程之间的分配率。

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

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

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

recorder