记我的一次JVM监控

环境： 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的，这种情况下，不如使用单例有效率，至于原因，忘记了。等任务完后，我会试验下，这种修改的效果。