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 spaceat 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