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不会强制使用许可证密钥或类似的东西。
甲骨文公司的马克·雷因霍尔德 （ 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 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.jfrJCMD实用程序提供了其他故障排除选项 。
分析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