大多数锁，在它们的生命周期中，从来不会被多于一个线程所访问。即使在极 少数情况下，多个线程真的共享数据了，锁也不会发生竞争。为了理解偏向锁的 优势，我们首先需要回顾一下如何获取锁（监视器）。

获取锁的过程分为两部分。首先，你需要获得一份契约.一旦你获得了这份契 约，就可以自由地拿到锁了。为了获得这份契约，线程必须执行一个代价昂贵的 原子指令。释放锁同时就要释放契约。根据我们的观察，我们似乎需要对一些锁 的访问进行优化，比如线程执行的同步块代码在一个循环体中。优化的方法之一 就是将锁粗化，以包含整个循环。这样，线程只访问一次锁，而不必每次进入循 环时都进行访问了。但是，这并非一个很好的解决方案，因为它可能会妨碍其他 线程合法的访问。还有一个更合理的方案，即将锁偏向给执行循环的线程。

将锁偏向于一个线程，意味着该线程不需要释放锁的契约。因此，随后获取锁 的时候可以不那么昂贵。如果另一个线程在尝试获取锁，那么循环线程只需要释 放契约就可以了。Java 6的HotSpot/JIT默认情况下实现了偏向锁的优化。

Java 6中的线程优化真的有效么？(2)

简析锁粗化（Lock coarsening explained）

另一种线程优化方式是锁粗化（或合并，merging）。当多个彼此靠近的同步 块可以合并到一起，形成一个同步块的时候，就会进行锁粗化。该方法还有一种 变体，可以把多个同步方法合并为一个方法。如果所有方法都用一个锁对象，就 可以尝试这种方法。考虑图2中的实例。

public static String concatToBuffer(StringBuffer sb, String s1, String s2, String s3) { sb.append(s1); sb.append(s2); sb.append(s3); return }

图2. 使用非局部的StringBuffer连接字符串

在这个例子中，StringBuffer的作用域是非局部的，可以被多个线程访问。所 以逸出分析会判断出StringBuffer的锁不能安全地被忽略。如果锁刚好只被一个 线程访问，则可以使用偏向锁。有趣的是，是否进行锁粗化，与竞争锁的线程数 量是无关的。在上面的例子中，锁的实例会被请求四次：前三次是执行append方 法，最后一次是执行toString方法，紧接着前一个。首先要做的是将这种方法进 行内联。然后我们只需执行一次获取锁的操作（为整个方法），而不必像以前一 样获取四次锁了。

这种做法带来的真正效果是我们获得了一个更长的临界区，它可能导致其他线 程受到拖延从而降低吞吐量。正因为这些原因，一个处于循环内部的锁是不会被 粗化到包含整个循环体的。

线程挂起 vs. 自旋（Thread suspending versus spinning）

在一个线程等待另外一个线程释放某个锁的时候，它通常会被操作系统挂起。 操作在挂起一个线程的时候需要将它换出CPU，而通常此时线程的时间片还没有使 用完。当拥有锁的线程离开临界区的时候，挂起的线程需要被重新唤醒，然后重 新被调用，并交换上下文，回到CPU调度中。所有这些动作都会给JVM、OS和硬件 带来更大的压力。

在这个例子中，如果注意到下面的事实会很有帮助：锁通常只会被占有很短的 一段时间。这就是说，如果能够等上一会儿，我们可以避免挂起线程的开销。为 了让线程等待，我们只需将线程执行一个忙循环（自旋）。这项技术就是所谓的 自旋锁。

当锁被占有的时间很短时，自旋锁的效果非常好。另一方面，如果锁被占有很 长时间，那么自旋的线程只会消耗CPU而不做任何有用的工作，因此带来浪费。自 从JDK 1.4.2中引入自旋锁以来，自旋锁被分为两个阶段，自旋十个循环（默认值 ），然后挂起线程。

自适应自旋锁（Adaptive spinning）

JDK 1.6中引入了自适应自旋锁。自适应意味着自旋的时间不再固定了，而是 取决于一个基于前一次在同一

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