介绍 — Java 6中的线程优化

　　Sun、IBM、BEA和其他公司在各自实现的Java 6虚拟机上都花费了大量的精力优化锁的管理和同步。诸如偏向锁（biased locking）、锁粗化（lock coarsening）、由逸出（escape）分析产生的锁省略、自适应自旋锁（adaptive spinning）这些特性，都是通过在应用程序线程之间更高效地共享数据，从而提高并发效率。尽管这些特性都是成熟且有趣的，但是问题在于：它们的承诺真的能实现么？在这篇由两部分组成的文章里，我将逐一探究这些特性，并尝试在单一线程基准的协助下，回答关于性能的问题。

　　悲观锁模型

　　Java支持的锁模型绝对是悲观锁（其实，大多数线程库都是如此）。如果有两个或者更多线程使用数据时会彼此干扰，这种极小的风险也会强迫我们采用非常严厉的手段防止这种情况的发生——使用锁。然而研究表明，锁很少被占用。也就是说，一个访问锁的线程很少必须等待来获取它。但是请求锁的动作将会触发一系列的动作，这可能导致严重的系统开销，这是不可避免的。

　　我们的确还有其他的选择。举例来说，考虑一下线程安全的StringBuffer的用法。问问你自己：是否你曾经明知道它只能被一个线程安全地访问，还是坚持使用StringBuffer，为什么不用StringBuilder代替呢？

　　知道大多数的锁都不存在竞争，或者很少存在竞争的事实对我们作用并不大，因为即使是两个线程访问相同数据的概率非常低，也会强迫我们使用锁，通过同步来保护被访问的数据。“我们真的需要锁么？”这个问题只有在我们将锁放在运行时环境的上下文中观察之后，才能最终给出答案。为了找到问题的答案，JVM的开发者已经开始在HotSpot和JIT上进行了很多的实验性的工作。现在，我们已经从这些工作中获得了自适应自旋锁、偏向锁和以及两种方式的锁消除（lock elimination）——锁粗化和锁省略（lock elision）。在我们开始进行基准测试以前，先来花些时间回顾一下这些特性，这样有助于理解它们是如何工作的。