我是靠谱客的博主 轻松书本,最近开发中收集的这篇文章主要介绍记我的一次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的,这种情况下,不如使用单例有效率,至于原因,忘记了。等任务完后,我会试验下,这种修改的效果。

最后

以上就是轻松书本为你收集整理的记我的一次JVM监控的全部内容,希望文章能够帮你解决记我的一次JVM监控所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(64)

评论列表共有 0 条评论

立即
投稿
返回
顶部