实验7-java虚拟机(JVM)调优案例分析与MyEclipse性能调优实战.pptVIP

一、实战：MyEclipse运行性能调优 很多Java开发人员都有这样一种观念：系统调优的工作都是针对服务端应用而言，规模越大的系统，就越需要专业的调优运维团队参与。这个观点不能说不对，上一节中笔者所列举的案例确实都是服务端运维、调优的例子，但服务端应用需要调优，并不说明其他应用就不需要了，作为一个普通的Java开发人员，前面讲的各种虚拟机的原理和最佳实践方法距离我们并不遥远，开发者身边很多场景都可以使用上面这些知识。下面通过一个普通程序员日常工作中可以随时接触到的开发工具开始这次实战。 1.1 MyEclipse调优前的程序运行状态 MyEclipse初始配置：找到myeclipse.ini文件，查看原始配置 1.2 VisualVm监控MyEclipse的原始情况 1.3 VisualVm监控myeclipse结果分析 从图中可以看出，仅启动过程就有350次young gc，21次full gc。为了查看gc细节，在myeclipse.ini中加入如下参数： -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D:/jvmlog/eclipse_gc.log gc的内容如下： 1.3 VisualVm监控myeclipse结果分析与调优 1.3 VisualVm监控myeclipse结果分析与调优 1.4 VisualVm监控myeclipse GC结果分析与调优 从gc日志中可以看出： （1）young区开始为960K，持续的不够，因此造成不断的young gc （2）full gc时，old区的空间增大扩容，从89312k增加到98724k，因此old区空间也不够 为了防止这种情况发生，加入以下参数： -Xms768m -Xmx768m -XX:NewSize=512m -XX:MaxNewSize=512m 1.4 VisualVm监控myeclipse运行结果分析与调优 此次调整后结果如下图 1.4 VisualVm监控myeclipse运行结果分析与调优 从图中可以看出，young gc没有了，但为什么还有14次full gc呢？ 以下是此次gc的日志： 1.4 VisualVm监控myeclipse运行结果分析与调优 从gc.log中，可以看出，是因为perm区的没有空间了，才导致的full gc，于是将perm区增大并固定大小 加入以下参数： -XX:PermSize=96m -XX:MaxPermSize=96m 此次调整后结果如下图： 从图中结果可以看出，没有full gc了，而且young gc只有2次，有了一定的效果了 1.4 VisualVm监控myeclipse运行结果分析与调优 1.5 VisualVm监控myeclipse运行结果分析与调优 启动时gc的问题解决了，现在来看其他问题： 1.5 VisualVm监控myeclipse运行结果分析与调优 从图中可以看出，如果classloader加载class的时间能快些，应该也会节省些时间 加入以下参数： -Xverify:none（关闭Java字节码验证，从而加快了类装入的速度） 1.5 VisualVm监控myeclipse运行结果分析与调优 1.5 VisualVm监控myeclipse运行结果分析与调优 将上两图比较 第一个：平均每个类的载入时间为，3.211/13708 = 0.000234242777939889s 第二个：平均每个类的载入时间为，2.314/11725= 0.0001973560767590618s 可以看出，多少是有一些性能上的提高的 1.6 VisualVm监控myeclipse运行结果分析与调优 考虑到eclipse长时间运行，其他可能调节的有以下几点： （1）关闭System.gc() （2）提高eclipse中某些代码的JIT编译 （3）优化垃圾收集器，以减少垃圾收集造成应用无响应的时间 对于（1），加入以下参数： -XX:+DisableExplicitGC 对于（2），会影响启动速度，但由于eclipse是长时间运行，因此此优化是必要的： -XX:CompileThreshold=100（方法调用多少次就会被编译成本地机器码） 1.6 VisualVm监控myeclipse运行结果分析与调优 1.6 VisualVm监控myeclipse运行结果分析与调优 可以看出，编译方法的数量和时间明显增加 对于（3），换用CMS收集器应该比串行收集器要好，加入以下参数： -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 至此，