在多核的世界中，线程间共享数据的现实呈现出一种全新的面貌。所有现代的 CPU必须使用本地存储的缓存，将获取指令和数据的延迟降到最低。当我们使用锁 的时候，会导致一次存储关卡（Barrier）被插入到执行路径中。存储关卡像一个 信号，它通知CPU此时必须和其他所有的CPU进行协调，以此获得最新的数值。为 了完成这个任务，CPU之间将要彼此通讯，从而导致每个处理器暂定当前正在运行 的应用程序线程。这个过程要花多少时间已经成了CPU存储模型的指标之一。越是 保守的存储模型，越是线程安全的，但是它们在协调各个处理器核的时候也要花 费更多的时间。在Core 2 Duo上，第二个核将固定的运行基准从3731ms提高到了 6574ms，或者说增加了176%。很明显，Hotspot所提供的任何帮助都能明显改进我 们的应用程序的总体性能。

逸出分析真的起作用了么？

现在，还有一种优化很明显会起作用，但是我们还没有考虑，它就是锁省略。 锁省略是最近才实现的技术，而且它依赖于逸出分析，后者是一种Profiling 技 术，其自身也是刚刚才实现的。为了稳妥一些，各公司和组织都宣称这些技术只 有在有限的几种情况下才起作用。比如，在一个简单的循环里，对一个局部变量 执行递增，且该操作被包含在一个同步块内，由一个局部的锁保护着。这种情况 下逸出分析是起作用的[http://blog.nirav.name/2007_02_01_archive.html]。 同时它在Mont Carlo的Scimark2基准测试中可以工作（参见 [http://math.nist.gov/scimark2/index.html]）。

Java 6中的线程优化真的有效么？——第二部分(5)

将逸出分析包含在测试中

那么，为什么逸出分析可以用于上述的情况中，却不能用于我们的基准测试中 ？我曾经尝试过将StringBuffer和 StringBuilder的部分方法进行内联。我也修 改过代码，希望可以强制逸出分析运行。我想看到锁最终被忽略，而性能可以获 得大幅提升。老实说，处理这个基准测试的过程既困惑，又让人倍感挫折。我必 须无数次地在编辑器中使用ctrl-z，以便恢复到前面一个我认为逸出分析应该起 作用的版本，但是却不知由于什么原因，逸出分析却突然不起作用了。有时，锁 省略却又会莫名其妙地出现。

最后，我认识到激活锁省略似乎和被锁对象的数据大小有关系。你运行清单2 的代码就会看到这一点。正如你所看到的，无论运行多少次，结果都毫无区别， 这说明DoEscapeAnalysi没有产生影响。

>java -server -XX:-DoEscapeAnalysis EATest thread unsafe: 941 ms. thread safe: 1960 ms. Thread safety overhead: 208% >java -server -XX:+DoEscapeAnalysis EATest thread unsafe: 941 ms. thread safe: 1966 ms. Thread safety overhead: 208%

在下面的两次运行中，我移除了ThreadSafeObject类中一个没有被用过的域。 如你所见，当开启了逸出分析，所有性能有了很大的提高。

>java -server -XX:-DoEscapeAnalysis EATest thread unsafe: 934 ms. thread safe: 1962 ms. Thread safety overhead: 210% >java -server -XX:+DoEscapeAnalysis EATest thread unsafe: 933 ms. thread safe: 1119 ms. Thread safety overhead: 119%

逸出分析的数目在Windows和Linux上都能看到。然而在Mac OS X上，即使有额 外未被使用的变量也不会有任何影响，任何版本的基准测试的结果都是120%。这 让我不由地相信在Mac OS X上有效性的范围比其他系统更广泛。我猜测这是由于 它的实现

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!