Java并发编程学习——Java并发机制的底层实现原理（volatile、synchronized、原子操作）

刺骨的言语ヽ痛彻心扉 2022-05-23 03:49 265阅读 0赞

前言

Java代码在经过编译后变为Java字节码，通过JVM执行字节码，最终转化为汇编指令在CPU上执行。需要我们了解的是：Java中所使用的并发机制依赖于JVM的实现和CPU的指令。本次我们就来跟随方腾飞老师的脚步一起简单了解一下Java并发机制的底层实现原理。

## **　1、**volatile的应用 ##

在多线程并发编程中synchronized和volatile都有重要作用。volatile可以理解为轻量级的synchronized，它在多线程开发中保证了共享变量的“可见性”。并且***volatile修饰的变量如果使用恰当***，执行成本低于synchronized，因为***不会引起线程上下文的切换和调度***。本节将深入分析在硬件层面上是如何实现volatile的，帮助大家正确的使用volatile变量。**<**

### **　1.1、**volatile的定义与实现原理 ###

在Java语言规范第三版中，volatile的定义为：Java编程语言允许线程访问共享变量，为了确保共享变量能够被准确和一致地更新，线程应该确保通过排它锁单独获得这个变量。

因为有了volatile，在某些情况下会比使用锁更加方便。若一个字段被声明为volatile，则Java线程内存模型确保所有线程看到的这个变量的值是一直的。在了解加实现原理之前，首先简单了解与其实现原理相关的CPU术语与说明。

<table> CPU的术语定义 
 <tbody> 
 <tr> 
 <td>术语</td> 
 <td>英文单词</td> 
 <td>术语描述</td> 
 </tr> 
 <tr> 
 <td>内存屏障</td> 
 <td>memory barriers</td> 
 <td>是一组处理器指令，用于实现对内存操作的顺序限制</td> 
 </tr> 
 <tr> 
 <td>缓冲行</td> 
 <td>cache line</td> 
 <td>CPU高速缓存中可以分配的最小存储单位。处理器填写缓冲行时会加载整个缓冲行，现代CPU需要执行几百次CPU指令。 </td> 
 </tr> 
 <tr> 
 <td>原子操作</td> 
 <td>atomic operations</td> 
 <td>不可中断一个或一系列操作</td> 
 </tr> 
 <tr> 
 <td>缓冲行填充</td> 
 <td>cache line fill</td> 
 <td>当处理器识别到从内存中读取操作数是可缓存的，处理器读取整个缓存行到适当的缓存（L1，L2，L3的或所有）</td> 
 </tr> 
 <tr> 
 <td>缓存命中</td> 
 <td>cache hit</td> 
 <td>如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问的地址时，处理器从缓存中读取操作数，而不是从内存。</td> 
 </tr> 
 <tr> 
 <td>写命中</td> 
 <td>write hit</td> 
 <td>当处理器将操作数写回到一个内存缓存的区域时，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数写回到缓存，而不是写回到内存，这个操作被称为写命中。</td> 
 </tr> 
 <tr> 
 <td>写缺失</td> 
 <td>write misses the cache</td> 
 <td>一个有效的缓存行被写入到不存在的内存区域。</td> 
 </tr> 
 </tbody> 
</table>

那么Volatile是如何来保证可见性的呢？

在x86处理器下通过工具获取JIT编译器生成的汇编指令来看看对Volatile进行写操作CPU会做什么事情。

<table style="border-spacing:0px;width:852px;margin:0px 0px 1em;background-color:rgb(255,255,255);color:rgb(102,102,102);line-height:35px;padding:0px;border:0px;"> 
 <tbody> 
 <tr> 
 <td style="padding:15px;margin:0px;border-color:rgb(204,204,204);">Java代码：</td> 
 <td style="padding:15px;margin:0px;border-color:rgb(204,204,204);">instance = new Singleton();//instance是volatile变量</td> 
 </tr> 
 <tr> 
 <td style="padding:15px;margin:0px;border-color:rgb(204,204,204);">汇编代码：</td> 
 <td style="padding:15px;margin:0px;border-color:rgb(204,204,204);">0x01a3de1d: movb $0x0,0x1104800(%esi);0x01a3de24:&nbsp;lock&nbsp;addl $0x0,(%esp);</td> 
 </tr> 
 </tbody> 
</table>

有volatile变量修饰的共享变量进行写操作的时候会多第二行汇编代码，通过开发者手册可知，Lock前缀的指令在多核处理器下回引发两件事情：

1.  将当前处理器缓存航中的数据写会到系统内存。
2.  这个写回内存的操作会使在其他CPU里面缓存了该内存地址的数据无效。

处理器为了提高处理速度，不直接和内存进行通讯，而是先将系统内存的数据读到内部缓存（L1,L2或其他）后再进行操作，但操作完之后不知道何时会写到内存。如果对声明了Volatile变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存（此时就应该使其他CPU里面缓存了该数据地址的数据无效）。但是就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题，所以在多处理器下，为了保证各个处理器的缓存是一致的，就会***实现缓存一致性协议***，每个处理器通过***嗅探在总线上传播的数据来检查自己缓存的值是不是过期了***，当处理器发现自己缓存行对应的***内存地址被修改***，就会将当前处理器的***缓存行设置成无效状态***，当处理器要对这个数据进行***修改操作***的时候，会***强制重新从系统内存里把数据读到处理器缓存里。***

下面具体讲解volatile的两条实现原则：

1.  Lock前缀指令会引起处理器缓存回写到内存。Lock前缀指令导致在执行指令期间，产生声言处理器的 LOCK\# 信号。在多处理器环境中，*LOCK\# 信号确保在声言该信号期间，处理器可以独占使用任何共享内存*（会锁总线，令其他CPU无法访问总线，进而不能访问系统内存）。在最近的处理器中，LOCK＃信号***一般不锁总线，而是锁缓存***（锁总线的开销较大）。在P6和最近的处理器中，如果***访问的内存区域已经缓存在处理器内部***，则不会声言LOCK\#信号。相反地，它***会锁定这块内存区域的缓存并回写到内存***，并使用缓存一致性机制来确保修改的原子性，此操作被称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。  
    
2.  一个处理器的缓存回写到内存会导致其他处理器的缓存无效。使用嗅探技术保证它的内部缓存，系统内存和其他处理器的缓存的数据在总线上保持一致。如果通过嗅探一个处理器来检测其他处理器打算写内存地址，而这个地址当前处理共享状态，那么正在嗅探的处理器将无效它的缓存行，在下次访问相同内存地址时，强制执行缓存行填充。

### **　1.2、volatile的使用优化** ###

在JDK 7的并发包中新增了一个队列集合类LinkedTransferQueue，它在使用volatile变量时，用一个准假字节的方式来优化队列出队和入队的性能。

LinkedTransferQueue勒种的AotomicReference会将共享变量追加到64字节，那么为什么追加到64字节能够提高并发编程的效率呢？因为对于很多CPU的处理器的L1、L2或L3缓存的告诉缓存行都是64个字节宽，不支持部分填充缓冲行，意味着，如果队列的头节点和尾节点都不足64字节，处理器会把他们读到同一个高速缓冲行中，在多处理器下每个处理器都会缓存相同的头节点、尾节点，*当一个处理器试图修改节点时，会将整个缓存行锁定，那么在缓存一致性机制的作用下，会导致其他处理器不能访问自己高速缓存中的节点*（锁缓存行，导致其他处理器不能访问自己高速缓存中的节点），而队列的入队和出队操作则需要不停修改头节点和尾节点，所以在多处理器的情况下回严重影响到队列的入队和出队效率。***追加到64字节的方式来填满高速缓冲区的缓存行，避免头节点和尾节点加载到同一个缓存行***，使头、尾节点在修改时不会相互锁定。

在以下两种情况不需要追加到64字节：

1.  缓存行非64字节宽的处理器。
2.  共享变量不会被频繁的写。使用追加字节的方式需要处理器读取更多的字节到高速缓冲区，会带来一定的性能消耗，如果共享变量不被频繁写的话，锁的概率就非常小，就没有必要通过追加字节的方式来避免相互锁定。

## **　2、synchronized的实现原理与应用** ##

本节基于方腾飞老师原文进行总结拓展，为尊重原文，原文地址为：[点击打开链接][Link 1]

**　　**在多线程并发编程中Synchronized一直是元老级角色，很多人都会称呼它为重量级锁，但是随着Java SE1.6对Synchronized进行了各种优化之后，有些情况下它并不那么重了。本节介绍了Java SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。

首先来说一下synchronized实现同步的基础：Java中每一个对象都可以作为锁。具体有以下3中形式

1.  **对于同步方法，锁是当前实例对象。**
2.  **对于静态同步方法，锁是当前对象的Class对象。**  
    
3.  **对于同步方法块，锁是Synchonized括号里配置的对象。**

当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。那么锁存在哪里呢？锁里面会存储的什么信息呢？

JVM规范规定JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit指令实现，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明，但是方法的同步同样可以使用这两个指令来实现。

![70][]

***　　monitorenter***指令是在***编译后插入到同步代码块的开始位置***，而monitorexit是插入到方法结束处和异常处， JVM要保证每个*monitorenter必须有对应的monitorexit与之配对*。任何对象都有一个 monitor 与之关联，***当且一个monitor 被持有后，它将处于锁定状态***。线程执行到 monitorenter 指令时，将会尝试获取对象所对应的 monitor 的所有权，即尝试获得对象的锁。

### **2.1、Java对象头** ###

synchronized锁存在Java对象头里。如果对象是数组类型，则虚拟机用3个Word（字宽）存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit。

<table> 
 <tbody> 
 <tr> 
 <td>长 &nbsp;度</td> 
 <td>内 &nbsp;容</td> 
 <td>说 &nbsp;明</td> 
 </tr> 
 <tr> 
 <td>32/64bit</td> 
 <td>Mark Word</td> 
 <td>存储对象的hashCode或锁信息等</td> 
 </tr> 
 <tr> 
 <td>32/64bit</td> 
 <td>Class Metadata Address</td> 
 <td>存储到对象类型数据的指针</td> 
 </tr> 
 <tr> 
 <td>32/64bit</td> 
 <td>Array length</td> 
 <td>数组的长度（如果当前对象是数组）</td> 
 </tr> 
 </tbody> 
</table>

Java对象头里的Mark Word里默认存储对象的HashCode，分代年龄和锁标记位。32位JVM的Mark Word的默认存储结构如下：

<table> Java对象头的存储结构 
 <tbody> 
 <tr> 
 <td>锁状态</td> 
 <td>25bit</td> 
 <td>4bit</td> 
 <td>1bit是否是偏向锁</td> 
 <td>2bit锁标志位</td> 
 </tr> 
 <tr> 
 <td>无锁状态</td> 
 <td>对象的hashCode</td> 
 <td>对象的分代年龄</td> 
 <td>0</td> 
 <td>01</td> 
 </tr> 
 </tbody> 
</table>

在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据（原谅小编不会打这个表格）：

![70 1][]

在64位虚拟机下，Mark Word是64bit大小的，其存储结构如下：

![70 2][]

### **2.2锁的升级与对比** ###

Java SE1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，在Java SE1.6里锁一共有四种状态，（级别从低到高依次为：）无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态。它们会随着竞争情况逐渐升级，但是锁可以升级不可以降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。

**2.2.1、偏向锁**

为了让线程获得锁的代价更低而引入了偏向锁。

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁，而只需简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁，如果测试成功，表示线程已经获得了锁，如果测试失败，则需要再测试下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁），如果没有设置，则使用CAS竞争锁，如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

**另一种解释**：

当锁对象第一次被线程获取的时候，虚拟机把对象头中的标志位设为“01”(就初始状态来说，是不变)，即偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中的偏向线程ID，并将是否偏向锁的状态位置置为1。

如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，直接检查ThreadId是否和自身线程Id一致， 如果一致，则认为当前线程已经获取了锁，虚拟机就可以不再进行任何同步操作（例如Locking、Unlocking及对Mark Word的Update等）。

当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就如上面介绍的轻量级那样执行。

**　　偏向锁的撤销**：偏向锁使用了一种**等到竞争出现才释放锁**的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向**锁的撤销，需要等待全局安全点**（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态，如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。下图中的线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程。

![70 3][]

关闭偏向锁：偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟-XX：BiasedLockingStartupDelay = 0。如果你确定自己应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁-XX:-UseBiasedLocking=false，那么默认会进入轻量级锁状态。

**　2.2.2、轻量级锁**

**轻量级锁加锁**：线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试***使用CAS将对象头中的Mark Word替换为指向锁记录的指针***。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

**轻量级锁解锁**：轻量级解锁时，会使用原子的CAS操作来将Displaced Mark Word替换回到对象头，如果*成功，则表示没有竞争发生*。如果*失败，表示当前锁存在竞争，锁就会膨胀成重量级锁*。下图是两个线程同时争夺锁，导致锁膨胀的流程图。

![70 4][]

自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁**升级成重量级锁，就不会再恢复到轻量级锁状态**。当锁处于这个状态下，**其他线程试图获取锁时，都会被阻塞住**，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

**　2.2.3、锁的优缺点对比**

<table> 锁的优缺点的对比 
 <tbody> 
 <tr> 
 <td>锁</td> 
 <td>优 &nbsp;点</td> 
 <td>缺 &nbsp;点</td> 
 <td>适用场景</td> 
 </tr> 
 <tr> 
 <td>偏向锁</td> 
 <td>加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距</td> 
 <td>如果线程间存在锁竞争，会带来额外的锁撤销的消耗</td> 
 <td>适用于只有一个线程访问同步块场景（个人认为较少线程也可以）</td> 
 </tr> 
 <tr> 
 <td>轻量级锁</td> 
 <td>竞争的线程不会阻塞，提高了程序的相应速度</td> 
 <td>如果使用得不到所竞争的线程，使用自旋会消耗CPU资源</td> 
 <td>追求响应时间同步块执行速度非常快</td> 
 </tr> 
 <tr> 
 <td>重量级锁</td> 
 <td>线程竞争不使用自旋，不会消耗CPU</td> 
 <td>线程会阻塞，响应时间缓慢</td> 
 <td>追求吞吐量同步块执行速度较长</td> 
 </tr> 
 </tbody> 
</table>

## **3.原子操作的实现原理** ##

原子（atomic）本意是“不能被进一步分割的最小粒子”，而**原子操作（atomic operation）意为”不可被中断的一个或一系列操作”** 。在多处理器上实现原子操作就变得有点复杂。

**　3.1、术语定义**

在了解原子操作的实现原理之前，首先简单了解一下相关的术语，如下表所示：

<table> CPU术语定义 
 <tbody> 
 <tr> 
 <td>术语名称</td> 
 <td>英 &nbsp;文</td> 
 <td>解 &nbsp;释</td> 
 </tr> 
 <tr> 
 <td>缓存行</td> 
 <td>Cache line</td> 
 <td>缓存的最小操作单位</td> 
 </tr> 
 <tr> 
 <td>比较并交换</td> 
 <td>Compare and Swap</td> 
 <td>CAS操作需要输入两个数值，一个旧值（期望操作前的值）和一个新值，在操作期间先比较旧值有没有发生变化，如果没有发生变化，才交换成新值，发生了变化则不交换。</td> 
 </tr> 
 <tr> 
 <td>CPU流水线</td> 
 <td>CPU pipeline</td> 
 <td>CPU流水线的工作方式就像工业生产上的装配流水线，在CPU中由5~6个不同功能的电路单元组成一条指令处理流水线，然后将一条X86指令分成5~6步后再由这些电路单元分别执行，这样就能实现在一个CPU时钟周期完成一条指令，因此提高CPU的运算速度。</td> 
 </tr> 
 <tr> 
 <td>内存顺序冲突</td> 
 <td>Memory order violation</td> 
 <td>内存冲突一般是由假共享引起的，假共享是指多个CPU同时修改同一个缓存行的不同部分而引起其中一个CPU的操作无效，当出现这个内存顺序冲突时，CPU必须清空流水线。</td> 
 </tr> 
 </tbody> 
</table>

**　3.2、处理器如何实现原子操作**

首先处理器会**自动保证基本的内存操作的原子性**。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。**奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的**，但是复杂的内存操作处理器不能自动保证其原子性，比如跨总线宽度，跨多个缓存行，跨页表的访问。但是处理器***提供总线锁定和缓存锁定***两个机制来保证复杂内存操作的原子性。

第一个机制是通过总线锁保证原子性。所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，**其他处理器的请求将被阻塞住**,那么该处理器可以独占使用共享内存。

第二个机制是通过缓存锁定保证原子性。在同一时刻我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把CPU和内存之间通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。

所谓“**缓存锁定**”是指内存区域如果被缓存在处理器的缓存行中，并且在Lock操作期间被锁定，那么当它执行所操作协会到内存的时候，处理器不再总线声言LOCK\#信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性。缓存一致性会阻止同时修改由两个以上处理器的内存区域数据，当**其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效**。

两种情况下处理器不会使用缓存锁定。

第一种情况是：**当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line），则处理器会调用总线锁定**。

第二种情况是：**有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定**。

**　3.3、Java如何实现源自操作**

在Java中通过**锁和循环CAS**的方式来实现原子操作。

**　3.3.1、使用循环CAS实现原子操作**

JVM中的CAS操作利用了处理器提供的CMPXCHG指令实现，自旋CAS实现的基本思路就是：循环进行CAS操作直到成功为止。

package atomic; import java.util.ArrayList; import java.util.List; import java.util.concurrent.atomic.AtomicInteger; /** * 实现了一个基于CAS线程安全的计数器方法safeCount和一个非线程安全的计数器count * @author LXH * */ public class Counter { private AtomicInteger atomicI = new AtomicInteger(0); private int i = 0; public static void main(String[] args) { final Counter cas = new Counter(); List<Thread> ts = new ArrayList<Thread>(600); long start = System.currentTimeMillis(); for(int j = 0; j < 100; j++) { Thread t = new Thread(new Runnable() { @Override public void run() { for(int i = 0; i < 10000; i++) { cas.count(); cas.safeCount(); } } }); ts.add(t); } for(Thread t : ts) { t.start(); } // 等待所有的线程执行完毕 for(Thread t : ts) { try { t.join(); } catch (Exception e) { e.printStackTrace(); } } System.out.println(cas.i); System.out.println(cas.atomicI); System.out.println(System.currentTimeMillis() - start); } /** * 使用CAS实现线程安全计数器 */ private void safeCount() { // 自旋 for(;;) { int i = atomicI.get(); // 比较，若相同则set，不同则不进行set，继续操作 boolean suc = atomicI.compareAndSet(i, ++i); if (suc) { break; } } } /** * 非线程安全的计数器 */ private void count() { i++; } }

运行结果：

![70 5][]

**　3.3.2、CAS实现原子操作的三大问题**

*  ABA问题

因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化，则进行更新。但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS不能检测它是否发生了变化。解决思路就是使用版本号，在变量的前面追加上版本号，每次变量更新的时候把版本号加1，那么就可以区分他们的变化。从Java 1.5开始，JDK的Atomic包中提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法首先检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，若全部相等，则以原子的方式将该引用和标志的值设置为给定的更新值。

*  循环时间长，开销大

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令，那么效率会有一定的提升。pause指令有两个作用：

1.  可以延迟流水线执行命令(de-pipeline)，使CPU不会消耗过多的执行资源。
2.  可以避免在退出循环的时候因内存顺序冲突而引起CPU流水线被清空，从而提高CPU执行效率

*  只能保持一个共享变量的原子操作

当对一个共享变量执行操作时，可以使用循环CAS的方式来保存原子操作，但是对多个共享操作时，循环CAS就无法保证操作的原子性，这个时候可以用锁。从Java 1.5开始AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

好了，就写到这吧。这其实是小编第好几次看这部分内容分了，终于把它整理出来了，希望能给有需要的童鞋一些帮助。啊，好困啊，现在是2018年6月2日1点32分，这是我完成你的时刻。睡觉去啦。有什么错误或见解，欢迎给小编留言啊。

[Link 1]: http://ifeve.com/java-synchronized/
[70]: /images/20220523/369ea5a7f6354923b8111f034badd116.png
[70 1]: /images/20220523/5db76e5860d2488f8079968b3e31e548.png
[70 2]: /images/20220523/ce00741a51844ae9b259d66a9d9b733b.png
[70 3]: /images/20220523/052a06f20a49449caca89ac78dfab0af.png
[70 4]: /images/20220523/38d3730182514cfb9fd2fc0210af90db.png
[70 5]: /images/20220523/990620486625454d99afdebf7bcd5938.png