转载

说一说 JVM 对锁的优化

讲正题之前，先说一下 ReentrantLock 和 synchronized 这对冤家，我们经常会拿这两个锁作比较，其中一个是显式锁，实现于 Lock 接口；而另外一个是隐式锁，更加的原生。

如果我们从性能上来比较的话，在 JDK 1.6 以前，多线程环境下的 synchronized 性能明显差于 ReentrantLock；但在 JDK 1.6 及其之后的版本中，两者的性能已经基本持平，而且我们通常优先考虑使用 synchronized 进行同步。究其原因，就是“锁优化”。

二. 自旋锁

其实自旋锁在 JDK 1.4.2 中已经引入，不过当时的默认状态为关闭；在 JDK 1.6 中改为默认开启。

1. 产生的原因

在互斥同步中，阻塞对性能的影响是最大的，挂起线程和恢复线程两个操作（即线程的切换）给了并发性能很大的压力。

但是很多时候，共享资源处于锁定状态的时间其实非常短，为了那么短的时间而去对线程反复地挂起与恢复明显十分不值得。因此我们可以利用自旋锁避免这两个操作。

2. 原理

当一个线程在请求一个被持有的锁时，让这个线程执行一个空循环（自旋），此时并不会放弃处理器的执行，如果锁很快就被释放，那么就避免了对这个线程的挂起与恢复操作。

3. 利弊得失

自旋本身避免了线程切换带来的开销，但也占用了处理器的时间。如果锁被占用的时间很短，那自旋锁的效果自然很好；但如果时间很长，那么这个自旋的线程就白白消耗了处理器的资源，反而适得其反，浪费了性能。

因此，自旋等待的时间是有限度的，一旦超过了自旋的限度次数，那么就会使用传统的方法进行阻塞，即挂起该线程。

4. 自适应自旋

JDK 1.6 中对自旋锁进行了改进，引入了自适应自旋锁，使得自旋的时间不再固定。简单来说，就是随着程序的运行和性能的监控，JVM 会对锁的情况进行预测，从而给出适合的自旋时间，更加 “智能”。

三. 锁消除

JVM 会对于一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。

例子：

public void add(String str1, String str2) {
    StringBuffer sb = new StringBuffer();
    sb.append(str1).append(str2);
}
复制代码

众所周知，StringBuffer 的 append 方法是同步方法，但是在这个 add 方法中，StringBuffer 不会存在共享资源竞争的情况，因为其他线程并不会访问到它。这就符合了 “代码上要求同步，但不可能存在共享数据竞争” 的条件。因此虽然这里有锁，但是可以安全地清除掉，避免了锁的获取释放带来的性能消耗。

四. 锁粗化

通常情况下，我们编写代码时，都尽可能地将同步块的作用范围缩小，使得锁的持有时间尽可能地缩短，提高细粒度，增加并发度，降低锁的竞争。

但是有些情况下，如果一系列连续的操作中我们不断地加锁解锁，比如在循环之中，那么也会造成不必要的性能损耗。

比如:

public void add(String str1, String str2, String str3) {
    StringBuffer sb = new StringBuffer();
    sb.append(str1);
    sb.append(str2);
    sb.append(str3);
}
复制代码

同样是 StringBuffer ，JVM 检测到有一连串操作都对同一个对象（sb）加锁时，就会把锁进行粗化处理，扩展同步范围，这样从一个 append() 到最后一个，只需要加一次锁就可以了。