记我的一次JVM监控

最新推荐文章于 2024-12-03 09:18:03 发布

乄浅醉

最新推荐文章于 2024-12-03 09:18:03 发布

阅读量685

点赞数

CC 4.0 BY-SA版权

分类专栏： java 文章标签： jvm

本文链接：https://blog.youkuaiyun.com/GG584741/article/details/51585609

java 专栏收录该内容

9 篇文章

订阅专栏

本文记录了一次针对使用JDK1.8在Ubuntu 16.04上的JVM监控实践。程序主要负责预热网站二维码图片，通过并行流处理，维持17个线程。监控显示，随着运行时间增加，Major GC或Full GC频率上升。优化措施是将生成二维码和压缩图片的工具类改为单例模式，结果显著降低了磁盘IO的峰值，改善了系统性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

环境： jdk1.8 ubuntu 16.04

先看图

上面两张图片是jconsole监控界面，程序已运行超过12小时。

先说下程序吧：主要是用来网站二维码图片的预热，生成300*300的大小的二维码，并且调用ImageMagick将图片压缩未90大小。

  public static void generate(List<String> list){

        list.parallelStream().forEach(title -> generate(title));
    }

同时使用了java8 并行流，所以看到了开启了多线程，并且线程数量一直稳定在17.

从上图也可以看出，java8并行流使用的是fork/join框架，并开启了3个worker。

从老年代内存分析图片上可以看出，随着程序运行的时间越长，内存回收越来越频繁（major GC 或者Full GC，无论哪种GC，都会找出STW），这几张监控图片是我稍微做了下程序优化后的监控。下面贴出未监控的图片：

两张图片线程数都是17，没有啥变化，唯一显著的变化的就是发生major GC或者full GC的时间延长了，当时忘记截图GC发生的时间了。

但是有两张图片可以看出程序优化后的效果：

优化前：

优化后：

从磁盘IO监控上看，优化的后的程序，磁盘IO不会一直飚的那么高了，只是偶尔会高下。我最直观的感受就是，我打开文件夹没有那么卡了。（PS：这是我的开发机器）

其实我做的优化很简单，将原来生成二维码和压缩图片的工具类修改为单例模式。当时有人问我，为什么不把 new 对象的操作放到循环外？我印象中，看过一本书关于JVM的，这种情况下，不如使用单例有效率，至于原因，忘记了。等任务完后，我会试验下，这种修改的效果。