南京 网站制作公司,文创产品设计作品,网站一般用什么语言做,开封企业网站建设recorderJava Flight Recorder#xff08;JFR#xff09;曾经是Oracle JDK的商业附加组件。 由于它最近与Java Mission Control一起开源#xff0c;因此使用OpenJDK 11的每个人现在都可以免费使用此出色的工具对Java应用程序进行故障排除。 JFR以前是专有解决方案#xff0… recorder Java Flight RecorderJFR曾经是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 BlockingQueuebyte[] 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:filegc.log:utctime,uptime,tid,level:filecount10,filesize128m \-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPathheapdump.hprof \-XX:StartFlightRecording\disktrue, \dumponexittrue, \filenamerecording.jfr, \maxsize1024m,\maxage1d,\settingsprofile \path-to-gc-rootstrue \OOMEGenerator Started recording 1.
Use jcmd 5469 JFR.dump name1 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 name1
14647:
Recording 1: name1 maxsize1.0GB maxage1d (running) 除此之外 JFR.dump允许您导出到目前为止已记录的所有内容而不必等待正在运行的JVM终止或停止记录。 %jcmd 5469 JFR.dump name1 filenamedump.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 RecorderJFR是一种概要分析工具用于从正在运行的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.htmlrecorder
