Java虚拟机对内部锁的四种优化方式

转载自：https://blog.youkuaiyun.com/broadview2006/article/details/78132983

  

锁消除

  锁消除是JIT编译器对内部锁的具体实现所做的一种优化。
  在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问。如果同步块所使用的锁对象只能够被一个线程访问，那么JIT编译器在编译这个同步块的时候并不生成synchronized所表示的锁的申请与释放对应的机器码，而仅生成原临界区代码对应的机器码，即消除了锁的使用。这种编译器优化就被称为锁消除，它使得特定情况下我们可以完全消除锁的开销。

  例如，StringBuffer虽然是线程安全的，但是在实际使用中往往不在多个线程间共享这些类的实例。而这些类在实现线程安全的时候往往借助于内部锁。因此，这些类是锁消除优化的常见目标。
  锁消除优化还可能需要以JIT编译器的内联优化为前提。而一个方法是否会被JIT编译器内联取决于该方法的热度以及该方法对应的字节码的尺寸（Bytecode Size)。因此，锁消除优化能否被实施还取决于被调用的同步方法（或者带同步块的方法）是否能够被内联。

  

锁粗化

  锁粗化是JIT编译器对内部锁的具体实现所做的一种优化。
  对于相邻的几个同步块，如果这些同步块使用的是同一个锁实例，那么JIT编译器会将这些同步块合并为一个大同步块，从而避免了一个线程反复申请、释放同一个锁所导致的开销。然而，锁粗化可能导致一个线程持续持有一个锁的时间变长，从而使得同步在该锁之上的其他线程在申请锁时的等待时间变长。因此，锁粗化不会被应用到循环体内的相邻同步块。

  

偏向锁

  偏向锁是Java虚拟机对锁的实现所做的一种优化。这种优化基于 大多数锁并没有被争用，并且这些锁在其整个生命周期内至多只会被一个线程持有。然而，Java虚拟机在实现monitorenter字节码（申请锁）和monitorexit字节码（释放锁）时需要借助一个原子操作（CAS操作），这个操作代价相对来说比较昂贵。因此，Java虚拟机会为每个对象维护一个偏好，即一个对象对应的内部锁第1次被一个线程获得，那么这个线程就会被记录为该对象的偏好线程（Biased Thread）。这个线程后续无论是再次申请该锁还是释放该锁，都无须借助原先（指未实施偏向锁优化前）昂贵的原子操作，从而减少了锁的申请与释放的开销。

  

适应性锁

  适应性锁是JIT编译器对内部锁实现所做的一种优化。
  存在锁争用的情况下，一个线程申请一个锁的时候如果这个锁恰好被其他线程持有，那么这个线程就需要等待该锁被其持有线程释放。实现这种等待的一种保守方法——将这个线程暂停（线程的生命周期状态变为非Runnable状态）。由于暂停线程会导致上下文切换，因此对于一个具体锁实例来说，这种实现策略比较适合于系统中绝大多数线程对该锁的持有时间较长的场景，这样才能够抵消上下文切换的开销。另外一种实现方法就是采用忙等，所谓忙等相当于一个循环体为空的循环语句。
  可见，忙等是通过反复执行空操作（什么也不做）直到所需的条件成立为止而实现等待的。这种策略的好处是不会导致上下文切换，缺点是比较耗费处理器资源——如果所需的条件在相当长时间内未能成立，那么忙等的循环就会一直被执行。因此，对于一个具体的锁实例来说，忙等策略比较适合于绝大多数线程对该锁的持有时间较短的场景，这样能够避免过多的处理器时间开销。

  事实上，Java虚拟机也不是非要在上述两种实现策略之中择其一 ——它可以综合使用上述两种策略。对于一个具体的锁实例，Java虚拟机会根据其运行过程中收集到的信息来判断这个锁是属于被线程持有时间“较长”的还是“较短”的。对于被线程持有时间“较长”的锁，Java虚拟机会选用暂停等待策略；而对于被线程持有时间“较短”的锁，Java虚拟机会选用忙等等待策略。Java虚拟机也可能先采用忙等等待策略，在忙等失败的情况下再采用暂停等待策略。Java虚拟机的这种优化就被称为适应性锁，这种优化同样也需要JIT编译器介入。
  适应性锁优化可以是以具体的一个锁实例为基础的。也就是说，Java虚拟机可能对一个锁实例采用忙等等待策略，而对另外一个锁实例采用暂停等待策略。
  从适应性锁优化可以看出，内部锁的使用并不一定会导致上下文切换，这就是说锁“可能”导致上下文切换的原因。