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 由于性能方面的原因依然没有吸引我们升级的亮点。

查看英文原文： State of Performance and Stability in Java 7 Update 1