java内存模型中锁的内存语义及种类（三十六）

柔光的暖阳◎ 2023-01-01 01:58 200阅读 0赞

今天分析 java内存模型中锁的内存语义及种类

**1、锁的内存语义**

当线程释放锁时， JMM  会把该线程对应的本地内存中的共享变量刷新到主 内存中。

当线程获取锁时， JMM  会把该线程对应的本地内存置为无效。从而使得被 监视器保护的临界区代码必须从主内存中读取共享变量。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

如果我们回顾第一章的  VolatileCase ，我们知道，为了让子线程可以及时看 到 *ready*  变量的修改，我们需要将  ready  变量以  volatile  来修饰。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

但是，当我们将程序做如下改造

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

我们可以看见子线程同样可以中止，为何？我们观察  System.out.println  的实 现

![20201230165113639.png][]

结合前面锁的内存语义，我们可以知道，当进入  **synchronized**  语句块时，子 线程会被强制从主内存中读取共享变量，其中就包括了 ready  变量，所以子线程 同样中止了。

**2、synchronized**  **的实现原理**

Synchronized  在  JVM  里的实现都是基于进入和退出  Monitor  对象来实现方法 同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的 MonitorEnter 和  MonitorExit  指令来实现。 对同步块，MonitorEnter  指令插入在同步代码块的开始位置，当代码执行到 该指令时，将会尝试获取该对象 Monitor  的所有权，即尝试获得该对象的锁，而 monitorExit 指令则插入在方法结束处和异常处，JVM 保证每个  MonitorEnter  必须 有对应的 MonitorExit 。 对同步方法，从同步方法反编译的结果来看，方法的同步并没有通过指令 monitorenter 和  monitorexit  来实现，相对于普通方法，其常量池中多了 ACC\_SYNCHRONIZED 标示符。JVM 就是根据该标示符来实现方法的同步的：当方法被调用时，调用指令将 会检查方法的 ACC\_SYNCHRONIZED  访问标志是否被设置，如果设置了，执行线 程将先获取 monitor ，获取成功之后才能执行方法体，方法执行完后再释放 monitor。在方法执行期间，其他任何线程都无法再获得同一个  monitor  对象。 synchronized 使用的锁是存放在  Java  对象头里面，

![20201230165143194.png][]

具体位置是对象头里面的  MarkWord ， MarkWord  里默认数据是存储对象的 HashCode 等信息，

![20201230165200278.png][]

但是会随着对象的运行改变而发生变化，不同的锁状态对应着不同的记录存 储方式

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

**3、了解各种锁**

**1）自旋锁 （1.6之后默认开启）*原理***

自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么 那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状 态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这 样就避免用户线程和内核的切换的消耗。 但是线程自旋是需要消耗 CPU  的，说白了就是让  CPU  在做无用功，线程不 能一直占用 CPU  自旋做无用功，所以需要设定一个自旋等待的最大时间。 如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会 导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止 自旋进入阻塞状态。

***2）自旋锁的优缺点***

自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非 常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起操 作的消耗！

但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块， 这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用 cpu  做无用 功，线程自旋消耗大于线程阻塞挂起操作的消耗，其它需要  cup 的线程又不能获取到 cpu ，造成  cpu  的浪费。

***3）自旋锁时间阈值***

自旋锁的目的是为了占着  CPU  的资源不释放，等到获取到锁立即进行处理。 但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处 于自旋状态占用 CPU  资源，进而会影响整体系统的性能。因此自旋次数很重要 JVM 对于自旋次数的选择，jdk1.5 默认为  10  次，在  1.6  引入了适应性自旋锁， 适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的 自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是 最佳的一个时间。

JDK1.6 中 \-XX:+UseSpinning  开启自旋锁；  JDK1.7  后，去掉此参数，由  jvm  控 制；

***4）自旋锁总结***

该锁就是获取锁失败后，为了避免直接让线程进入阻塞状态而采取的循环一定次数去试着获取锁的行为。（因为线程进入阻塞状态和退出阻塞状态是涉及到操作系统管理层面的，需要从用户态进入内核态，非常消耗系统资源），为什么能这样做呢？是因为试验证明，锁的持有时间一般是非常短的，所以一般多次尝试就能竞争到锁，另外该锁和后面要说的轻量级锁原理基本是一样的。

**4、锁的状态（** **Synchronized的锁** **）**

一共有四种状态， **无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态** ， 它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和 释放锁的效率。

**偏向锁（1.6之后加入的新型锁机制）原理**

引入背景：大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多 次获得，为了让线程获得锁的代价更低而引入了偏向锁，减少不必要的 CAS  操作。 偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中， 同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步 的，减少加锁／解锁的一些 CAS  操作（比如等待队列的一些  CAS  操作），这种 情况下，就会给线程加一个偏向锁。 如果在运行过程中，遇到了其他线程抢占 锁，则持有偏向锁的线程会被挂起，JVM  会消除它身上的偏向锁，将锁恢复到标 准的轻量级锁。它通过消除资源无竞争情况下的同步原语，进一步提高了程序的 运行性能。 偏向锁获取过程：

步骤 1 、 访问  Mark Word  中偏向锁的标识是否设置成  1 ，锁标志位是否为 01，确认为可偏向状态。

步骤  2 、 如果为可偏向状态，则测试线程  ID  是否指向当前线程，如果是， 进入步骤 5 ，否则进入步骤  3 。

步骤  3 、 如果线程  ID  并未指向当前线程，则通过  CAS  操作竞争锁。如果竞 争成功，则将 Mark Word  中线程  ID  设置为当前线程  ID ，然后执行  5 ；如果竞争 失败，执行 4 。

步骤  4 、 如果  CAS  获取偏向锁失败，则表示有竞争。当到达全局安全点 （safepoint ）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞 在安全点的线程继                续往下执行同步代码。（撤销偏向锁的时候会导致 stop the word）

步骤  5 、 执行同步代码。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

偏向锁的释放：

偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向 锁时，持有偏向锁的线程才会释放偏向锁，线程不会主动去释放偏向锁。偏向锁 的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首 先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复 到未锁定（标志位为“01”）或轻量级锁（标志位为“ 00 ”）的状态。 偏向锁的适用场景 始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去 执行同步块，在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁，升级 为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致 stop the word  操 作；在有锁的竞争时，偏向锁会多做很多额外操作，尤其是撤销偏向所的时候会导致 进入安全点，安全点会导致 stw，导致性能下降，这种情况下应当禁用。 jvm 开启 / 关闭偏向锁

开启偏向锁： \-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

关闭偏向锁： \-XX:-UseBiasedLocking

偏向锁总结：

偏向锁是指在对象实例的Mark Word（对象内存中的开头几个字节保留的信息，如果把一个对象序列化后明显可以看见开头的这些信息），为了在线程竞争不激烈的情况下，减少加锁及解锁的性能损耗，则在Mark Word中有保存这上次使用这个对象锁的线程ID信息，如果这个线程再次请求这个对象锁，那么只需要读取该对象上的Mark Word的偏向锁信息（也就是线程id）跟线程本身的id进行对比，如果是同一个id就直接认为该id获得锁成功，而不需要在进行真正的加解锁操作。就是你上次来过了，这次又来，并且在这两次之间没有其他人来过，对于这个线程来说，锁对象的资源随便用都是安全的。这是用缓存原理来换取性能的做法，不过偏向锁在锁竞争不激烈的情景下使用才能获取比较高的效率。当使用CAS竞争偏向锁失败，表示竞争比较激烈，偏向锁升级为轻量级锁。

**轻量级锁（1.6之后加入的新型锁机制）**

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

在代码进入同步块的时候，如果同步对象锁状态为无锁状态且不允许进行偏向 （锁标志位为“01 ”状态，是否为偏向锁为“ 0 ”），虚拟机首先将在当前线程 的栈帧中建立一个名为锁记录（Lock Record ）的空间，用于存储锁对象目前的 Mark Word 的拷贝，官方称之为  Displaced Mark Word 。 拷贝成功后，虚拟机将使用 CAS  操作尝试将对象的  Mark Word  更新为指向  Lock Record 的指针，并将  Lock record  里的  owner  指针指向  object mark word 。如果更 新成功，则执行步骤 4 ，否则执行步骤  5 。 如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word 的锁标志位设置为“ 00 ”，即表示此对象处于轻量级锁定状态 如果这个更新操作失败了，虚拟机首先会检查对象的 Mark Word  是否指向当前 线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进 入同步块继续执行。否则说明多个线程竞争锁，当竞争线程尝试占用轻量级锁失 败多次之后，轻量级锁就会膨胀为重量级锁，重量级线程指针指向竞争线程，竞 争线程也会阻塞，等待轻量级线程释放锁后唤醒他。锁标志的状态值变为“10 ”， Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也 要进入阻塞状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

**轻量级锁总结：**

轻量级锁是比偏向锁更耗资源的锁,实现机制是,线程在竞争轻量级锁前,在线程的栈内存中分配一段空间作为锁记录空间(轻量级锁对应的对象的对象头的字段的拷贝),拷贝好后,线程通过CAS去竞争这个对象锁，试图把对象的对象头子段改成指向所记录空间，如果成功则说明获取轻量级锁成功，如果失败，则进入自旋（循环）取试着获取锁。如果自旋到一定次数还是不能获取到锁，则进入重量级锁。

**5、重量级锁**

重量级锁，就是最开始java实现的阻塞锁。在JVM中又叫对象监视器。这时的锁对象的对象头字段指向的是一个互斥量，所有线程竞争重量级锁，竞争失败的线程进入阻塞状态（操作系统层面），并且在锁对象的一个等待池中等待被唤醒，被唤醒后的线程再次去竞争锁资源。在1.6版本前，只要加了 **synchronized，**  就只有重量级锁这种情况。

**6、** **不同状态锁的比较**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

** 7、锁升级的总结：**

锁升级即从**无锁->偏向锁->轻量级锁(自旋锁)->重量级锁**，其实从本质上说，开始与 java从1.6版本开始对synchronized同步机制的性能优化，1.6之前的synchronized同步机制是直接跳过前几个步骤，进入重量级锁，而重量级锁因为需要线程进入阻塞状态（从用户态进入内核态）这种操作系统层面的操作非常消耗资源，因此，synchronized同步机制就显得很重，效率不高。那么为了解决这个问题，java才引入了偏向锁，轻量级锁，自旋锁这几个概念。通俗的讲，偏向锁是为了避免CAS（自旋）操作，尽量在比较对象头时就把加锁问题解决掉，只有在冲突的情况下才指向一次CAS操作，而轻量级锁和自旋锁呢，其实两个是一块使用的，为的是尽量避免线程进入内核的阻塞状态（对性能非常不利），试图用CAS操作和循环把加锁问题解决掉，而重量级锁是最终的无奈解决方案，总之、通过内存读取判断解决优化方案优于通过CAS操作方案和CAS空循环方案优于CPU阻塞，唤醒线程的方案。

**8、JDK**  **对锁的更多优化措施**

***1）逃逸分析***

如果证明一个对象不会逃逸方法外或者线程外，则可针对此变量进行优化： 同步消除 synchronization Elimination ，如果一个对象不会逃逸出线程，则对此变 量的同步措施可消除。

***2）锁消除和粗化***

锁消除：虚拟机的运行时编译器在运行时如果检测到一些要求同步的代码上不可 能发生共享数据竞争，则会去掉这些锁。 锁粗化：将临近的代码块用同一个锁合并起来。

消除无意义的锁获取和释放，可以提高程序运行性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221120/0cb84810efc346e492e544ee6f57e156.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221120/cde53a1b22cb40c9aef58fa402e2e3cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221120/e1abba342d8148aebcac2b4e9990ad36.png
[20201230165113639.png]: /images/20221120/a5522560d3c34456abbbf4e0f022640d.png
[20201230165143194.png]: /images/20221120/8b278b649dfa47158093000a624faeaf.png
[20201230165200278.png]: /images/20221120/548990c85f9d4ab1915aa786aa3f66ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221120/5a719528f15f4d27886f52669b6936c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221120/d803ff671b664091907c12fc5be136c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221120/48f3f8d621894b4ebf1a53fca46c8df5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221120/676bf95494144661bb0700528c825a87.png