Java虚拟机是怎么实现synchronized的

在Java程序中，可以利用synchronized关键字来对程序进行加锁。它既可以用来声明一个synchronized代码块，也可以直接标记静态方法或者实例方法。

当声明synchronized代码块时，编译而成的字节码将包含monitorenter和monitorexit指令。这两种指令均会消耗操作数栈上的一个引用类型的元素(synchronized关键字括号里的引用)，作为所要加锁解锁的锁对象。

synchronized 代码块字节码

  public void foo(Object lock) {
    synchronized (lock) {
      lock.hashCode();
    }
  }
  // 上面的Java代码将编译为下面的字节码
  public void foo(java.lang.Object);
    Code:
       0: aload_1
       1: dup
       2: astore_2
       3: monitorenter
       4: aload_1
       5: invokevirtual java/lang/Object.hashCode:()I
       8: pop
       9: aload_2
      10: monitorexit
      11: goto          19
      14: astore_3
      15: aload_2
      16: monitorexit
      17: aload_3
      18: athrow
      19: return
    Exception table:
       from    to  target type
           4    11    14   any
          14    17    14   any

//字节码中包含一个monitorenter指令以及多个monitorexit指令。  
//JVM需要确保所获得的锁在正常执行路径，以及异常执行路径上都能够被解锁。

当用synchronized标记方法时，字节码中方法的访问标记包括ACC_SYNCHRONIZED。该标记表示在进入该方法时，JVM需要进行monitorenter操作；而在退出该方法时，不管是正常返回，还是向调用者抛异常，JVM均需要进行monitorexit操作。

synchronized 方法字节码

  public synchronized void foo(Object lock) {
    lock.hashCode();
  }
  // 上面的Java代码将编译为下面的字节码
  public synchronized void foo(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0021) ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=1, locals=2, args_size=2
         0: aload_1
         1: invokevirtual java/lang/Object.hashCode:()I
         4: pop
         5: return

//monitorenter和monitorexit操作所对应的锁对象是隐式的。  
//对于实例方法来说，这两个操作对应的锁对象是this；  
//对于静态方法来说，这两个操作对应的锁对象则是所在类的Class实例。

关于monitorenter和monitorexit的作用，可以抽象的理解为每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针。

当执行monitorenter时，如果目标锁对象的计数器为0，那么说明它没有被其他线程所持有。在这个情况下，JVM会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。

在目标锁对象的计数器不为0的情况下，如果锁对象的持有线程是当前线程，那么JVM可以将其计数器加1，否则需要等待，直到持有线程释放该锁。

当执行monitorexit时，JVM则需将锁对象的计数器减1，当计数器减为0时，那便代表该锁已经被释放掉了。

采用这种计数器的方式，是为了允许同一个线程重复获取同一把锁。如果一个Java类中拥有多个synchronized方法，那么这些方法之间的相互调用，不管是直接的还是间接的，都会涉及对同一把锁的重复加锁操作。需要设计这么一个可冲入的特性，来避免编程里的隐式约束。

重量级锁

重量级锁是JVM中最为基础的锁实现。在这种状态下，JVM会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程。

Java线程的阻塞以及唤醒，都是依靠操作系统来完成的。对于符合posix接口的操作系统(macOS和大部分Linux)，上述操作是通过pthread的互斥锁(mutex)来实现的。此外，这些操作将涉及系统调用，需要从操作系统的用户态切换至内核态，其开销非常之大。

为了避免昂贵的线程阻塞、唤醒操作，JVM会在线程进入阻塞状态之前，以及被唤醒后竞争不到锁的情况下，进入自旋状态，在处理器上空跑并且轮询锁是否被释放。如果此时锁恰好被释放了，那么当前线程便无须进入阻塞状态，而是直接获得这把锁。

与线程阻塞相比，自旋状态可能会浪费大量的处理器资源。这是因为当前线程仍处于运行状况，只不过跑的是无用指令。它期望在运行无用指令的过程中，锁能够被释放出来。

JVM么有办法根据等待时间的长短来选择自旋还是阻塞。JVM啊啊给出的是自适应自旋，根据以往自旋等待时是否能够获得锁，来动态调整自旋的时间(循环数目)。

自旋状态带来另外一个副作用-不公平的锁机制。处于阻塞状态的线程，并没有办法立刻竞争被释放的锁。然而，处于自旋状态的线程，则很有可能优先获得这把锁。

轻量级锁

多个线程在不同的时间段请求同一把锁，没有锁竞争。针对这种情形，JVM采用了轻量级锁，来避免重量级锁的阻塞以及唤醒。

在对象内存布局中，对象头中的标记字段(mark word)。它的最后两位被用来表示该对象的锁状态。其中00代表轻量级锁，01代表无锁(或偏向锁)，10代表重量级锁，11则跟垃圾回收算法的标记有关。

synchronized原理和锁优化策略(偏向/轻量级/重量级)

synchronized原理和锁优化策略-轻量级锁

JVM的开发者发现在很多情况下，在Java程序运行时，同步块中的代码都是不存在竞争的，不同的线程交替的执行同步块中的代码。这种情况下，用重量级锁是没必要的。因此JVM引入了轻量级锁的概念。

轻量级锁是由偏向所升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。

加锁过程

1. 在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁记录目前的Mark Word的拷贝（称为Displaced Mark Word）以及记录锁对象的指针（即obj（即下图的Object reference）字段指向锁对象）。下图右边的部分就是一个Lock Record。左边部分是锁对象。

   

2. 当一个线程来获取这个锁，虚拟机将使用CAS操作尝试将锁对象的Mark Word更新为指向Lock Record的指针。

• 如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后2bit）将转变为“00”，即表示此对象处于轻量级锁定状态。
• 如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否已经指向当前线程的栈帧。
  • 如果已经指向当前线程的栈帧，说明当前线程已经拥有了这个对象的锁，现在是重入状态，那么：
    • 设置Lock Record第一部分（Displaced Mark Word）为null，起到了一个重入计数器的作用。
    • 下图为重入三次时的lock record示意图，左边为锁对象，右边为当前线程的栈帧。
    • 然后结束。就可以直接进入同步块继续执行。

      为什么JVM选择在线程栈中添加Displaced Mark word为null的Lock Record来表示重入计数呢？首先锁重入次数是一定要记录下来的，因为每次解锁都需要对应一次加锁，解锁次数等于加锁次数时，该锁才真正的被释放，也就是在解锁时需要用到说锁重入次数的。一个简单的方案是将锁重入次数记录在对象头的mark word中，但mark word的大小是有限的，已经存放不下该信息了。另一个方案是只创建一个Lock Record并在其中记录重入次数，Hotspot没有这样做的原因我猜是考虑到效率有影响：每次重入获得锁都需要遍历该线程的栈找到对应的Lock Record，然后修改它的值。所以最终Hotspot选择每次获得锁都添加一个Lock Record来表示锁的重入。

  • 如果已经指向别的线程的栈帧，说明这个锁对象已经被其他线程抢占了。那么：
    • 它就会自旋等待锁，一定次数后仍未获得锁对象，说明发生了竞争，需要膨胀为重量级锁。

解锁过程

1. 遍历当前线程栈,找到所有obj字段等于当前锁对象的Lock Record。
2. 如果Lock Record的Displaced Mark Word为null，代表这是一次重入，将obj设置为null后continue（即一次解锁结束）。
3. 如果Lock Record的Displaced Mark Word不为null，则利用CAS指令将对象头的mark word恢复成为Displaced Mark Word。如果成功，则continue（即一次解锁结束），否则膨胀为重量级锁。

加锁

当进行加锁操作时，JVM会判断是否已经是重量级锁。如果不是，它会在当前线程的当前栈帧中划出一块空间，作为该锁的锁记录，并且将锁对象的标记字段复制到该锁记录中。然后，JVM会尝试用CAS(compare-and-swap)操作替换锁对象的标记字段。

CAS是一个原子操作，它会比较目标地址的值是否和期望值相等，如果相等，则替换为一个新的值。

假设当前锁对象的标记字段为X…XYZ，JVM会比较该字段是否为X…X01。

• 如果是，则替换为刚才分配的锁记录的地址（当前线程当前栈帧中的一块空间）。由于内存对齐的缘故，它的最后两位为00。此时，该线程已成功获得这把锁，可以继续执行了。
• 如果不是X…X01，那么有两种可能：第一，该线程重复获取同一把锁。此时，JVM会将锁记录清零，以代表该锁被重复获取。第二，其他线程持有该锁。此时，JVM会将这把锁膨胀为重量级锁，并且阻塞当前线程。

  通过标记字段所指向的轻量级锁锁记录是否在自己栈上判断。

解锁

当进行解锁操作时，如果当前锁记录(可以将一个线程的所有锁记录想象成一个栈结构，每次加锁压入一条锁记录，解锁弹出一条锁记录，当前锁记录指的便是栈顶的锁记录)的值为0，则代表重复进入同一把锁，直接返回即可。

否则，JVM会尝试用CAS操作，比较锁对象的标记字段的值是否为当前锁记录的地址。如果是，则替换为锁记录中的值，也就是锁对象原本的标记字段。此时，该线程已经成功释放这把锁。如果不是，则意味着这把锁已经被膨胀为重量级锁。此时，JVM会进入重量级锁的释放过程，唤醒因竞争该锁而被阻塞了的线程。

偏向锁

偏向锁针对的情况更加乐观：从始至终只有一个线程请求一把锁。

在线程进行加锁时，如果该锁对象支持偏向锁，那么JVM会通过CAS操作，将当前线程的地址记录在锁对象的标记字段之中，并且将标记字段的最后三位设置为101。

在接下来的运行过程中，每当有线程请求这把锁，JVM只需要判断锁对象标记字段中：最后三位是否为101，是否包含当前线程的地址，以及epoch值是否和所对象的类的epoch值相同。如果都满足，那么当前线程持有该偏向锁，可以直接返回。

当请求加锁的线程和锁对象标记字段保持的线程地址不匹配时(而且epoch值相等，如若不等，那么当前线程可以将该锁重偏向至自己)，JVM需要撤销该偏向锁。这个撤销过程非常麻烦，它要求持有偏向锁的线程到达安全点，再将偏向锁替换成轻量级锁。

---

如果某一类锁对象的总撤销数超过了一个阈值(JVM参数-XX:BiasedLockingBulkRebiasThreshold，默认为20)，那么JVM会宣布这个类的偏向锁失效。进行批量重偏向。

具体的做法便是在每个类中维护一个epoch值，可以理解为第几代偏向锁。当设置偏向锁时，JVM需要将该epoch值复制到锁对象的标记字段中。

在宣布某个类的偏向锁失效时，JVM实则将该类的epoch值加1，表示之前那一代的偏向锁已经失效。而新设置的偏向锁则需要复制新的epoch值。

为了保证当前持有偏向锁并且已加锁的线程不至于因此丢所，JVM需要遍历所有线程的Java栈，找出该类已加锁的实例，并且将它们标记字段中的epoch值加1。该操作需要所有线程处于安全点状态。

如果总撤销数超过另一个阈值(JVM参数-XX:BiasedLockingBulkRevokeThreshold，默认值为40)，那么JVM会认为这个类已经不再适合偏向锁。此时，JVM会撤销该类实例的偏向锁，并且在之后的加锁过程中直接为该类实例设置轻量级锁。

总结

JVM中synchronized关键字的实现，按照代价由高到低可分为重量级锁、轻量级锁和偏向锁三种。

重量级锁会阻塞、唤醒请求加锁的线程。它针对的是多个线程同时竞争同一把锁的情况。JVM采取了自适应自旋，来避免线程在面对非常小的synchronized代码块时，仍会被阻塞、唤醒的情况。

轻量级锁采用CAS操作，将锁对象的标记字段替换为一个指针，指向当前线程上的一块空间，存储着锁对象原本的标记字段。它针对的是多个线程在不同时间段申请同一把锁的情况。

偏向锁只会在第一次请求时采用CAS操作，在锁对象的标记字段中记录下当前线程的地址。在之后的运行过程中，持有该偏向锁的线程的加锁操作将直接返回。它针对的是锁仅会被同一线程持有的情况。