Java 7 Update 1的性能和稳定性测试

　　Oracle于10月18日发布了Java 7 Update 1，给Java 7 带来了迫切需要增强的稳定性，并且修复了我们以前报道过的HotSpot编译器的性能优化问题，这个问题偶尔会导致错误结果甚至导致SIGSEV崩溃。JDK 6 Update 29在使用不推荐用于生产服务器的参数XX:+AggressiveOpts或者-XX:+OptimizeStringConcat时，也存在相同的问题，这在此次更新中也得到了修复。

　　在Java HotSpot虚拟机性能增强文档中，Oracle 描述了其他一些与性能相关的特性。这份简短的文档只包含一项改进：-XX:+TieredCompilation。

　　分层编译在早先编译器的混合模式行为上增加了额外的一步。服务器会先对JVM分级，然后Java 7才会在解释模式下运行代码。然后代码只会在“热”的时候才被编译和优化，并被HotSpot VM标记，比如说有较高的执行次数。解释模式无论如何都比运行编译后的代码慢很多。-XX:+TieredCompilation让虚拟机可以在已经运行编译后代码的同时，收集用于优化的统计信息。

　　尽管这项改变可能会减少高动态性系统的预热时间，其中节点会不断地与服务器连接，但是它带来的改进并不十分明显，就像桌面或者applet程序的启动没那么重要一样。

　　以下列出的针对JVM 7的改进对于Java 6都已经生效：

　　Compressed Oops自Java 6 Update 14有效，自Update 23成为默认设置(仅64位)

　　Escape Analysis自Java 6 Update 14有效，自Update 23成为默认设置

　　非统一内存访问垃圾回收(Non Uniform Memory Access Garbage Collection)自Java 6 Update 2有效

　　Compressed Oops会为64位地址的JVM节省内存。JVM将使用更简短的地址来引用与堆起点相关的对象，而不是从操作系统获得64位内存地址。由于减少了对象引用的内存使用，大多数程序都会受益于这项特性。

　　Escape Analysis会查明新分配内存的对象是否要“脱离”当前方法的作用域。如果不是那样，那么该对象就可能会被分配在方法栈上，甚至同步可能会被移除(锁省略)。Heinz Kabutz就该项优化的效果有一篇全面的文章。

　　非统一内存访问垃圾回收是一项很有意义的改进，其实已经存在很长一段时间了。在现代内存架构中，有一些内存区比别的内存区的读写操作快。特别是在多核系统中，有些内存是专为个体CPU保留的。感兴趣的读者可以从Ulrich Drepper优秀的文章中更多地了解这些内存区。JVM将尝试在执行分配内存线程的核所使用的内存中分配对象的内存。该性能改进要求很高(特别是在Solaris机器上)，但是-XX:+UseNUMA选项从来都不是默认的。

　　随着大部分改进在Java 6 Updates上可用(乃至成为默认项)，Java 7由于性能方面的原因依然没有吸引我们升级的亮点。

原文转自：http://www.ltesting.net