Java 7 Update 1的性能和稳定性

作者 Fabian Lange 译者 钮玉晓 发布于 2011年12月15日

领域

语言 & 开发

主题

Java SE ,

垃圾回收 ,

Java ,

语言 ,

性能调优 ,

编程 ,

性能和可伸缩性

分享到

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

1. 返回顶部

   Tiered Compilation应该最终会替代掉client模式的。。。

   发表人 文 珂

   Tiered Compilation应该最终会替代掉client模式的。。。

   回复