ant jdk 小版本 不同 java class文件 差异,jdk6不同小版本Garbage collection性能差异问题 | 墙角的小猫's Blog...

其实很早注意到这个现象，但是一直没考虑到jdk本身的问题。相同的java代码跑出了不一样的速度，因为是两个不同的机器，想当然的归结为机器的性能差异。但是仔细研究过后，确认是oracle JDK本身的问题了。

下面是实验数据：

容器使用resin，jvm参数

-Xmx2548m

-Xms2548m

-Xmn512M

-Xss512K

-XX:PermSize=128M

-XX:MaxPermSize=128M

-XX:SurvivorRatio=8

-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC

-XX:+CMSPermGenSweepingEnabled

-XX:+CMSClassUnloadingEnabled

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0

-XX:+CMSParallelRemarkEnabled

-XX:+DisableExplicitGC

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=75

-XX:SoftRefLRUPolicyMSPerMB=0

老版本jdk，是杀掉java进程后重启的：完全无法回收，一直在做fullGC

[root@localhost /usr/local/java/bin]$ ./jstat -gccause 25515 1000

S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC

0.00 70.25 58.30 86.46 23.91 81 12.692 10 0.498 13.190 CMS Final Remark No GC

39.81 70.25 100.00 84.21 23.91 82 12.692 10 0.498 13.190 unknown GCCause Allocation Failure

0.00 76.34 66.34 83.26 23.91 83 12.841 10 0.498 13.339 unknown GCCause No GC

0.00 85.84 9.98 84.12 23.91 85 13.046 11 0.548 13.594 unknown GCCause No GC

68.63 0.00 64.33 84.99 23.91 86 13.165 11 0.548 13.713 unknown GCCause No GC

0.00 58.93 56.29 85.82 23.91 87 13.260 11 0.548 13.808 unknown GCCause No GC

68.76 0.00 73.34 85.82 23.91 88 13.327 11 0.548 13.875 unknown GCCause No GC

0.00 47.74 10.05 86.26 23.91 89 13.374 11 0.548 13.922 unknown GCCause No GC

42.41 0.00 65.30 85.37 23.91 90 13.420 12 0.686 14.106 unknown GCCause No GC

0.00 61.64 90.46 82.97 23.91 91 13.490 12 0.686 14.176 unknown GCCause No GC

42.80 62.41 0.00 78.90 23.91 93 13.580 13 0.686 14.266 No GC CMS Initial Mark

0.00 62.41 46.48 78.90 24.09 93 13.580 13 0.734 14.314 CMS Initial Mark No GC

更新JDK后同样杀掉java进程重启：可以正常回收内存

S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC

16.49 0.00 99.17 74.75 28.26 104 13.303 4 0.753 14.056 unknown GCCause No GC

0.00 13.23 5.91 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 16.86 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 24.91 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 35.45 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 38.63 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 43.78 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 48.12 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 53.89 75.05 28.26 105 13.328 5 0.756 14.085 CMS Initial Mark No GC

0.00 13.23 60.49 74.99 28.26 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 64.81 74.42 28.26 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 69.19 69.29 28.26 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 74.96 68.19 28.14 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 80.66 68.19 28.14 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 84.39 68.19 28.14 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 89.34 68.19 28.14 105 13.328 6 1.109 14.438 CMS Final Remark No GC

0.00 13.23 93.12 68.19 28.14 105 13.328 6 1.109 14.438 CMS Final Remark No GC

3.91 0.00 4.59 68.20 28.14 106 13.337 6 1.109 14.446 unknown GCCause No GC

之前的状况体现在shell脚本调用的定时java上，同样的配置同样的代码，北京机房的总比上海的快四五分钟跑完。更换了上海老版本jdk后，速度一致了。

实验结果证明java version “1.6.0_21″这个和更老的版本，GC回收或者说是内存管理性能较差。更新的版本确认到1.6.0_29没有这个问题，中间的版本没有尝试。

所以线上生产环境如果出现一样的java代码某些机器性能明显差异的话，可以检查下jdk版本，必要的时候需要更新解决。