《深入理解JAVA虚拟机》第五章调优案例分析与实战

桃扇骨 2022-03-19 06:38 124阅读 0赞

### 《深入理解java虚拟机 笔记》 ###

*  第五章 eclipse启动调优实战
 *   *  Eclipse运行速度调优实战
     *   *  取消字节码验证优化编译时间和类加载时间
         *  调整内存设置从而控制垃圾回收收集频率
         *  选择收集器降低延迟

# 第五章 eclipse启动调优实战 #

## Eclipse运行速度调优实战 ##

visualVM若没有安装VisualGC插件，需要先安装。若更新或安装时有时会出现建立连接时的问题，提示找不到系统文件，出现这种问题是因为地址出现了问题。  
  解决方法：工具—>插件—>设置,打开后出现如图所示  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70]  
  自己版本的JDK对应的插件需要先在https://visualvm.github.io/pluginscenters.html选择自己的版本，点击进入复制Catalog URL到工具—>插件—>设置的编辑中。我的是JDK1.7的地址为https://visualvm.github.io/archive/uc/7u60/updates.html，其中的Catalog URL  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 1]  
安装完后，如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 2]  
  然后再eclipse的初始配置文件eclipse.ini中配置增加一句：配置eclipse开启JMX管理。-Xms256m设置堆大小256M。  
    -Dcom.sun.mangement.jmxremote  
    -Xms256m  
    
  启动eclipse后，在visualVM中可查看我的eclipse启动情况：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 3]  
  而我的eclipse大约每7分钟左右会发生一次GC，很神奇，什么程序也没跑，堆中的内存(主要是eden space中)会缓慢的增长，增到满的时候会执行一次GC。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 4]  
我eclipse原始配置测试结果：  
  垃圾收集总耗时1.024S，发生了28次GC。  
  加载类19978个，耗时48.254秒。  
  JIT编译时间为1分30.585秒。  
  虚拟机256MB堆内存分配为102M新生代(98M的eden空间和4M的surviver)，159M老年代。  
  我eclipse启动约1分钟，没有用eclipse RCP开发进行测量，主要启动的时间耗时在compile time、class load time、GC time中。

按照书中章节，

*  升级JDK版本(感觉暂时不需要更高版本)
 *  取消字节码验证优化编译时间和类加载时间
 *  调整内存设置从而控制垃圾回收收集频率(我垃圾回收约1s，可以尝试)
 *  选择收集器降低延迟

### 取消字节码验证优化编译时间和类加载时间 ###

eclipse.ini中增加参数设置：禁止字节码验证  
    -Xverify:none  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 5]

发现：  
  编译时间从1分30.585秒变成1分17秒，加载类原来19978个。  
  耗时48.254秒变成加载17514个，耗时30.491秒。  
  新生代中的区域划分也发生改变。  
  若以完全加载完所有的类视为eclipse的启动时间，快了18秒左右。

### 调整内存设置从而控制垃圾回收收集频率 ###

可以看出，我虚拟机256MB堆内存第一次分配为102M新生代(98M的eden空间和4M的surviver)，159M老年代配置明显太小，导致eden或者老年代中容易空间耗尽，于是重新分配内存。将java堆固定为512M，永久代为120M(永久代的大小经过我测试发现会影响类加载的时间，适当自己调整)。  
参数设置：  
  -Xms512m  
  -Xmx512m  
  -Xmn128m  
  -XX:PermSize=120m  
  -XX:MaxPermSize=120m  
  -Dcom.sun.mangement.jmxremote  
  -Xverify:none  
      
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 6]  
  发现此时，发现此时JIT编译时间1分17秒变1分14、类加载时间30.41变成24.7，GC时间都有了减少。

### 选择收集器降低延迟 ###

此时eclipse已经启动的比较快了，eclipse没有使用纯运行10分钟的状况如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 7]  
  可以看出老年代比较大所以还没发生GC，而新生代发生了28次，每次使用时长大约56毫秒。而eclipse中启动的阶段，JIT编译，即在到20:26:38的半分钟中，CPU使用率也比较高，说明CPU使用的比较充分。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 8]  
  由于eclipse需要一边编译一边工作，回顾第三章的几种收集器，CMS是最符合这种场景的收集器。因此：加入-XX:+UseConcMarkSweepGC参数，使用CMS收集器作为默认的新生代收集器。  
参数设置：若在设置时出现无法创建虚拟机，很有可能参数设置冲突(我第一次冲突，去除了-XX:+UseG1GC -XX:+UseStringDeduplication)  
  -vmargs  
  -Dosgi.requiredJavaVersion=1.8  
  -Dosgi.instance.area.default=@user.home/eclipse-workspace  
  -Dosgi.requiredJavaVersion=1.8  
  -Xms512m  
  -Xmx512m  
  -Xmn128m  
  -XX:PermSize=120m  
  -XX:MaxPermSize=120m  
  -XX:+UseConcMarkSweepGC  
  -Dcom.sun.mangement.jmxremote  
  -Xverify:none  
启动结果:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 9]  
  可以看出离上次：编译时间1分14变成了1分4秒，类加载时间25秒变成26秒。老年代从0次GC变成了4次，但是新生代eden从每次约56毫秒变成了41毫秒。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70]: /images/20220319/92b6e9457a4b43e98fc8ebffc1cd61d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 1]: /images/20220319/43c8c358006c44ad92bd4519a598b40a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 2]: /images/20220319/54daf409b37643da8ce3ab344ee5d737.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 3]: /images/20220319/7b98151f5d3f49648af9da9493d862c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 4]: /images/20220319/a3e6765c3af04b3b9fb2c64a56eb318f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 5]: /images/20220319/88566879bbe94771b32be105bb3c963c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 6]: /images/20220319/8316f001852444289f0391fe4d5333d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 7]: /images/20220319/c62c9e47f86345a68a9a23b3ba538d11.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 8]: /images/20220319/0ff257dcb6354f3b966d35fc59fb42a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 9]: /images/20220319/232adbe16bfb496e9ee0ace43f1a6002.png