JUC多线程：synchronized 锁机制原理

前言：

        线程安全是并发编程中的重要关注点，造成线程安全问题的主要原因有两点，一是存在共享数据(也称临界资源)，二是存在多条线程共同操作共享数据。因此为了解决这个问题，我们可能需要这样一个方案，当存在多个线程操作共享数据时，需要保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再进行，这种方式叫互斥锁，即能达到互斥访问目的的锁，也就是说当一个共享数据被当前正在访问的线程加上互斥锁后，在同一个时刻，其他线程只能处于等待的状态，直到当前线程处理完毕释放该锁。

 1、synchronized 的作用：

         synchronized 通过当前线程持有对象锁，从而拥有访问权限，而其他没有持有当前对象锁的线程无法拥有访问权限，保证在同一时刻，只有一个线程可以执行某个方法或者某个代码块，从而保证线程安全。synchronized 可以保证线程的可见性，synchronized 属于隐式锁，锁的持有与释放都是隐式的，我们无需干预。synchronized最主要的三种应用方式：

• 修饰实例方法：作用于当前实例加锁，进入同步代码前要获得当前实例的锁
• 修饰静态方法：作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁
• 修饰代码块：指定加锁对象，进入同步代码库前要获得给定对象的锁

2、synchronized 底层语义原理：

        synchronized 锁机制在 Java 虚拟机中的同步是基于进入和退出监视器锁对象 monitor 实现的（无论是显示同步还是隐式同步都是如此），每个对象的对象头都关联着一个 monitor 对象，当一个 monitor 被某个线程持有后，它便处于锁定状态。在 HotSpot 虚拟机中，monitor 是由 ObjectMonitor 实现的，每个等待锁的线程都会被封装成 ObjectWaiter 对象，ObjectMonitor 中有两个集合，_WaitSet 和 _EntryList，用来保存 ObjectWaiter 对象列表 ，owner 区域指向持有 ObjectMonitor 对象的线程。当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合尝试获取 moniter，当线程获取到对象的 monitor 后进入 _Owner 区域并把 _owner 变量设置为当前线程，同时 monitor 中的计数器 count 加1；若线程调用 wait() 方法，将释放当前持有的 monitor，count自减1，owner 变量恢复为 null，同时该线程进入 _WaitSet 集合中等待被唤醒。若当前线程执行完毕也将释放 monitor 并复位变量的值，以便其他线程获取 monitor。如下图所示：

_EntryList：存储处于 Blocked 状态的 ObjectWaiter 对象列表。
_WaitSet：存储处于 wait 状态的 ObjectWaiter 对象列表。

3、 synchronized 的显式同步与隐式同步:

        synchronized 分为显式同步（同步代码块）和隐式同步（同步方法），显式同步指的是有明确的 monitorenter 和 monitorexit 指令，而隐式同步并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的。

3.1、synchronized 代码块底层原理：

        synchronized 同步语句块的实现是显式同步的，通过 monitorenter 和 monitorexit 指令实现，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置，当执行 monitorenter 指令时，当前线程将尝试获取 objectref（即对象锁）所对应的 monitor 的持有权：

• 当对象锁的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值设置为 1，取锁成功。
• 如果当前线程已经拥有对象锁的 monitor 的持有权，那它可以重入这个 monitor，重入时计数器的值也会加1。
• 若其他线程已经拥有对象锁的 monitor 的所有权，那当前线程将被阻塞，直到正在执行线程执行完毕，即monitorexit 指令被执行，执行线程将释放 monitor 并设置计数器值为0，其他线程将有机会持有 monitor。

        编译器会确保无论方法通过何种方式完成，无论是正常结束还是异常结束，代码中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令。为了保证在方法异常完成时，monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器可处理所有的异常，它的目的就是用来执行 monitorexit 指令。

3.2、synchronized 方法底层原理：

        synchronized 同步方法的实现是隐式的，无需通过字节码指令来控制，它是在方法调用和返回操作之中实现。JVM 可以通过方法常量池中的方法表结构（method_info Structure）中的 ACC_SYNCHRONIZED 访问标志 判断一个方法是否同步方法。当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，标识该方法是一个同步方法，执行线程将先持有 monitor， 然后再执行方法，最后再方法完成(无论是正常完成还是非正常完成)时释放 monitor。在方法执行期间，执行线程持有了 monitor，其他任何线程都无法再获得同一个 monitor。

        如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的 monitor 将在异常抛到同步方法之外时自动释放。

 4、JVM 对 synchronized 锁的优化：

        在早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁 monitor 是依赖于操作系统的 Mutex 互斥量来实现的，操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。在 JDK6 之后，synchronized 在 JVM 层面做了优化，减少锁的获取和释放所带来的性能消耗，主要优化方向有以下几点：

4.1、锁升级：偏向锁->轻量级锁->自旋锁->重量级锁

        锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，只能从低到高升级，不会出现锁的降级。重量级锁基于从操作系统的互斥量实现的，而偏向锁与轻量级锁不同，他们是通过 CAS 并配合 Mark Word 一起实现的。

4.1.1、synchronized 的 Mark word 标志位：

        synchronized 使用的锁对象是存储在 Java 对象头里的，那么 Java 对象头是什么呢？对象实例分为：

• 对象头
  • Mark Word
  • 指向类的指针
  • 数组长度
• 实例数据
• 对齐填充

其中，Mark Word 记录了对象的 hashcode、分代年龄、锁标记位相关的信息，由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到 JVM 的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，在 32位 JVM 中的长度是 32 位，具体信息如下图所示：

4.1.2、锁升级过程：

（1）偏向锁：如果一个线程获得了锁，那么进入偏向模式，当这个线程再次请求锁的时候，只需去对象头的 Mark Word 中判断偏向线程ID是否指向它自己，无需再进入 monitor 中去竞争对象，这样就省去了大量锁申请的操作，适用于连续多次都是同一个线程申请相同的锁的场景。偏向锁只有初始化的时候需要一次 CAS 操作，但如果出现其他线程竞争锁资源，那么偏向锁就会被撤销，并升级为轻量级锁。

（2）轻量级锁：不需要申请互斥量，允许短时间内的锁竞争，每次申请、释放锁都至少需要一次 CAS，适用于多个线程交替执行同步代码块的场景

（3）自旋锁：自旋锁假设在不久将来，当前的线程可以获得锁，因此在轻量级锁升级成为重量级锁之前，虚拟机会让当前想要获取锁的线程做几个空循环，在经过若干次循环后，如果得到锁，就顺利进入临界区，如果还不能获得锁，那就会将线程在操作系统层面挂起。

这种方式确实可以提升效率的，但是当线程越来越多竞争很激烈时，占用 CPU 的时间变长会导致性能急剧下降，因此 JVM 对于自旋锁有一定的次数限制，可能是50或者100次循环后就放弃，直接挂起线程，让出CPU资源。

（4）自适应自旋锁：自适应自旋解决的是 “锁竞争时间不确定” 的问题，自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

• 如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100个循环。
• 相反的，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能减少自旋时间甚至省略自旋过程，以避免浪费处理器资源。

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

（5）重量级锁：适用于多个线程同时执行同步代码块的场景，且锁竞争时间长。在这个状态下，未抢到锁的线程都会进入到 Monitor 中并阻塞在 _EntryList 集合中。

4.2、锁消除：

        消除锁属于编译器对锁的优化，JIT 编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)会使用逃逸分析技术，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间。

4.3、锁粗化：

        JIT 编译器动态编译时，如果发现几个相邻的同步块使用的是同一个锁实例，那么 JIT 编译器将会把这几个同步块合并为一个大的同步块，从而避免一个线程“反复申请、释放同一个锁“所带来的性能开销。

5、偏向锁的废除：

        在 JDK6 中引入的偏向锁能够减少竞争锁定的开销，使得 JVM 的性能得到了显著改善，但是 JDK15 却将决定将偏向锁禁用，并在以后删除它，这是为什么呢？主要有以下几个原因：

• 为了支持偏向锁使得代码复杂度大幅度提升，并且对 HotSpot 的其他组件产生了影响，这种复杂性已成为理解代码的障碍，也阻碍了对同步系统进行重构
• 在更高的 JDK 版本中针对多线程场景推出了性能更高的并发数据结构，所以过去看到的性能提升，在现在看来已经不那么明显了。
• 围绕线程池队列和工作线程构建的应用程序，性能通常在禁用偏向锁的情况下变得更好。

锁升级过程详细解析推荐阅读：掘金

参考文章：深入理解Java并发之synchronized实现原理_zejian的博客-CSDN博客_synchronized原理