JUC第四讲：Java中的锁/CAS原理与案例分析（下）

3.10、notifyAll 是怎么实现全唤起的？

• nofity 是获取 WaitSet 的头结点，执行唤起操作。
• nofityAll 的流程，可以简单的理解为就是循环遍历 WaitSet 的所有节点，对每个节点执行 notify 操作。

3.3、Volatile/Synchronized两者区别：（锁的目标：关注互斥性和可见性）

• 1、volatile仅能修饰变量；synchronized则可以使用在变量、方法、和类级别的
• 2、volatile仅能实现变量的修改可见性，并不能保证原子性；synchronized则可以保证变量的修改可见性和原子性
• 3、volatile非阻塞：确保新值立即同步到主存，其他线程每次使用前立即从主内存刷新；synchronized同步阻塞：释放锁之前会将对变量的修改刷新到主存当中
• 4、volatile标记的变量不会被编译器优化； synchronized标记的变量可以被编译器优化。

3.4、ReentrantLock实现原理？（可重入锁,底层是由AQS实现）

• 在Java5.0之前，协调共享对象的访问时可以使用的机制只有 synchronized 和 volatile。Java5.0后增加了一些新的机制，是当内置锁不适用时，作为一种可选择的高级功能。
• ReentrantLock 实现了Lock接口，通过这个接口可以实现同步访问,提供了比 Synchronized 关键字更灵活、更广泛、粒度更细的锁操作。

特点：

• 1、无锁的同步机制（非公平锁）
• 2、加锁和解锁都需要显示写出，实现了Lock接口，注意一定要在后面 unlock
• 3、可实现轮询锁、定时锁、可中断锁特性
• 4、提供一个condition类，对锁进行更精确的控制
• 5、默认使用非公平锁，可插队跳过对线程队列的处理

ReentrantLock 的内部类Sync继承了AQS，分为公平锁FairSync和非公平锁NonfairSync

• 1、公平锁：线程获取锁的顺序和调用lock的顺序一样，FIFO；浪费唤醒锁的时间；是否是AQS队列中的头结点
• 2、非公平锁：线程获取锁的顺序和调用lock的顺序无关，先执行lock方法的锁不一定先获得锁

优点：

• 1、显示锁可中断，防止死锁，内置锁不可中断，会产生死锁
• 2、可以实现非公平锁提高程序性能
• 3、实现其他特性的锁
• 4、对锁更精细的控制

3.5、Synchronized/ReentrantLock的区别 20181222

• 1、实现层面

• synchronized（JVM层面的锁）; Lock（JDK层面的锁）

• 2、响应中断

• 使用synchronized时，等待的线程会一直等待下去，不能够响应中断；Lock可以让等待锁的线程响应中断

• 3、立即返回

• 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间，而synchronized却无法办到；

• 4、读写锁

• Lock可以提高多个线程进行读操作的效率

• 5、可实现公平锁

• sychronized天生就是非公平锁** （怎么实现？）|Lock可以实现公平锁(fairness)

• 6、显式获取和释放

• Synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；
• 而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

• 7、性能上：随着近些年 synchronized 的不断优化，ReentrantLock 和 synchronized 在性能上已经没有很明显的差距了，所以性能不应该成为我们选择两者的主要原因。官方推荐尽量使用 synchronized，除非 synchronized 无法满足需求时，则可以使用 Lock

3.6、synchronized 锁升级流程？

核心流程如下图所示

• synchronized 加锁流程图
  

3.5、synchronized实现原理？（由一对monitorenter/monitorexit指令实现了同步的语义）

synchronized 的底层实现主要区分：方法和代码块，如下图例子。

public class SynchronizedDemo {
    private static final Object lock = new Object();
    public static void main(String[] args) {
        // 锁作用于代码块
        synchronized (lock) {
            System.out.println("hello word");
        }
    }
    // 锁作用于方法
    public synchronized void test() {
        System.out.println("test");
    }
}

将该代码进行编译后，查看其字节码，核心代码如下：

{
  public com.joonwhee.SynchronizedDemo();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 9: 0
  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: getstatic     #2                  // Field lock:Ljava/lang/Object;
         3: dup
         4: astore_1
         5: monitorenter   // 进入同步块  
         6: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         9: ldc           #4                  // String hello word
        11: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        14: aload_1
        15: monitorexit   // 退出同步块  
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit  // 退出同步块  
        22: aload_2
        23: athrow
        24: return
      Exception table:
         from    to  target type
             6    16    19   any
            19    22    19   any
  public synchronized void test();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED  // ACC_SYNCHRONIZED 标记
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #6                  // String test
         5: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 20: 0
        line 21: 8
}

• synchronized 修饰代码块时，编译后会生成 monitorenter 和 monitorexit 指令，分别对应进入同步块和退出同步块。可以看到有两个 monitorexit，这是因为编译时 JVM 为代码块添加了隐式的 try-finally，在 finally 中进行了锁释放，这也是为什么 synchronized 不需要手动释放锁的原因。
  
• synchronized 修饰方法时，编译后会生成 ACC_SYNCHRONIZED 标记，当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了则会先尝试获得锁。
  
• 两种实现其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
  

Synchronized的语义底层是通过一个monitor（监视器锁）对象来完成的，当monitor被占用时处于锁定状态

• 线程执行monitorenter指令时尝试获取monitor的所有权：

• 1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
• 2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数+1.
• 3、如果其他线程已经占用monitor，该线程进入阻塞状态，直到monitor的进入数为0，再尝试获取monitor的所有权

• 线程执行monitorexit指令完成锁的释放

• monitor的进入数-1，如果-1后进入数为 0，线程退出monitor;其他被monitor阻塞的线程尝试获取monitor

• 优化：

• 0、java6之前，Monitor的实现完全依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作时一个无差别的重量级操作；
• 1、代码优化：同步代码块、减少锁粒度、读锁并发
• 2、JVM对此进行了改进，提供三种不同的Monitor实现： 偏置锁、轻量级锁（CAS操作）、重量级锁（自适应自旋、锁粗化、锁消除）
• 3、后续版本的synchronized进行了较多改进，在低竞争场景中表现可能优于ReentrantLock

• 锁的升级降级：

• 当JVM检测到不同的竞争状况时，会自动切换到适合的锁实现，这种切换就是锁的升级、降级：当没有竞争出现时，默认会使用偏斜锁。
• JVM会利用CAS操作（compare and swap），在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。
• 如果有另外的线程试图锁定某个已经被偏斜过的对象，JVM就需要撤销（revoke）偏斜锁，并切换到轻量级锁实现。轻量级锁依赖CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。
• 降级：锁降级确实是会发生的，当JVM进入安全点（SafePoint）的时候，会检查是否有闲置的Monitor，然后试图进行降级

3.7、介绍下 Mark Word？

在介绍 Mark Word 之前，需要先了解对象的内存布局。 HotSpot 中，对象在堆内存中的存储布局可以分为三部分：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。

1）对象头（Header）

• 主要包含两类信息：Mark Word 和 类型指针。
• Mark Word 记录了对象的运行时数据，例如：HashCode、GC分代年龄、偏向标记、锁标记、偏向的线程ID、偏向纪元（epoch）等，32 位的 markword 如下图所示。

• 类型指针，指向它的类型元数据的指针，Java 虚拟机通过这个指针来确定该对象是哪个类的实例。如果对象是数组，则需要有一个用于记录数组长度的数据。

2）实例数据（Instance Data）

• 对象存储的真正有效信息，即我们在代码里定义的各种类型的字段内容。

3）对齐填充（Padding）

• Hotspot 要求对象的大小必须是8字节的整数倍，因此，如果实例数据不是8字节的整数倍时，需要通过该字段进行填充。

3.8、介绍下 Lock Record？

锁记录，这个大家应该都听过，用于轻量级锁时暂存对象的 markword。

Lock Record 在源码中为 BasicObjectLock，源码如下：

class BasicObjectLock VALUE_OBJ_CLASS_SPEC {
 private:
  BasicLock _lock;
  oop       _obj;
};
class BasicLock VALUE_OBJ_CLASS_SPEC {
 private:
  volatile markOop _displaced_header; 
};

其实就两个属性：

1）_displaced_header：用于轻量级锁中暂存锁对象的 markword，也称为 displaced mark word。

2）_obj：指向锁对象。

Lock Record 除了用于暂存 markword 之外，还有一个重要的功能是用于实现锁重入的计数器，当每次锁重入时，会用一个 Lock Record 来记录，但是此时 _displaced_header 为 null。

这样在解锁的时候，每解锁1次，就移除1个 Lock Record。移除时，判断 _displaced_header 是否为 null。如果是，则代表是锁重入，则不会执行真正的解锁；否则，代表这是最后一个 Lock Record，此时会真正执行解锁操作。

3.9、什么匿名偏向？

所谓的匿名偏向是指该锁从未被获取过，也就是第一次偏向，此时的特点是锁对象 markword 的线程 ID 为0。

当第一个线程获取偏向锁后，线程ID会从0修改为该线程的 ID，之后该线程 ID 就不会为0了，因为释放偏向锁不会修改线程 ID。

这也是为什么说偏向锁适用于：只有一个线程获取锁的场景。

3.10、偏向锁模式下 hashCode 存放在哪里？

偏向锁状态下是没有地方存放 hashCode 的。

因此，当一个对象已经计算过 hashCode 之后，就再也无法进入偏向锁状态了。

如果一个对象当前正处于偏向锁状态，收到需要计算其 hashCode 的请求时（Object::hashCode()或者System::identityHashCode（Object）方法的调用），它的偏向锁状态就会立即被撤销。

3.11、偏向锁流程？

首先，在开启偏向锁的时候，对象创建后，其偏向锁标记位为1。如果没开启偏向锁，对象创建后，其偏向锁标记位为0。

加锁流程：

1）从当前线程的栈帧中寻找一个空闲的 Lock Record，将 obj 属性指向当前锁对象。

2）获取偏向锁时，会先进行各种判断，如加锁流程图所示，最终只有两种场景能尝试获取锁：匿名偏向、批量重偏向。

3）使用 CAS 尝试将自己的线程 ID 填充到锁对象 markword 里，修改成功则获取到锁。

4）如果不是步骤2的两种场景，或者 CAS 修改失败，则会撤销偏向锁，并升级为轻量级锁。

5）如果线程成功获取偏向锁，之后每次进入该同步块时，只需要简单的判断锁对象 markword 里的线程ID是否自己，如果是则直接进入，几乎没有额外开销。

解锁流程：

• 偏向锁的解锁很简单，就是将 obj 属性赋值为 null，这边很重要的点是不会将锁对象 markword 的线程ID还原回0。
  
• 偏向锁流程中，markword 的状态变化如下图所示：
  
  

3.12、批量重偏向、批量撤销？启发式算法？

上面我们提到了批量重偏向，与批量重偏向同时被引入的还有批量撤销，官方统称两者为 “启发式算法”。

为什么引入启发式算法？

• 从上面的介绍我们知道，当只有一个线程获取锁时，偏向锁只需在第一次进入同步块时执行一次 CAS 操作，之后每次进入只需要简单的判断即可，此时的开销基本可以忽略。因此在只有一个线程获取锁的场景中，偏向锁的性能提升是非常可观的。
  
• 但是如果有其他线程尝试获得锁时，此时需要将偏向锁撤销为无锁状态或者升级为轻量级锁。偏向锁的撤销是有一定成本的，如果我们的使用场景存在多线程竞争导致大量偏向锁撤销，那偏向锁反而会导致性能下降。
  

JVM 开发人员通过分析得出以下两个观点：

• 观点1：对于某些对象，偏向锁显然是无益的。例如涉及两个或更多线程的生产者-消费者队列。这样的对象必然有锁竞争，而且在程序执行过程中可能会分配许多这样的对象。

• 该观点描述的是锁竞争比较多的场景，对这种场景，一种简单粗暴的方法是直接禁用偏向锁，但是这种方式并不是最优的。
  
• 因为在整个服务中，可能只有一小部分是这种场景，因为这一小部分场景而直接放弃偏向锁的优化，显然是不划算的。最理想的情况下是能够识别这样的对象，并只为它们禁用偏向锁。
  
• 批量撤销就是对该场景的优化。
  

• 观点2：在某些情况下，将一组对象重新偏向另一个线程是有好处的。特别是当一个线程分配了许多对象并对每个对象执行了初始同步操作，但另一个线程对它们执行了后续工作。

• 我们知道偏向锁的设计初衷是用于只有一个线程获取锁的场景。该观点中后半部分其实是符合这场场景的，但是由于前半部分而导致不能享受偏向锁带来的好处，因此 JVM 开发人员要做的就是识别出这场场景，并进行优化。
  
• 对于这种场景，官方引入了批量重偏向来进行优化。
  

• 批量重偏向

• JVM 选择以 class 为粒度，为每一个 class 维护了一个偏向锁撤销计数器。每当该 class 的对象发生偏向锁撤销的时候，计数器值+1。
  
• 当计数器的值超过批量重偏向的阈值（默认20）的时候，JVM 认为此时命中了上述的场景2，就会对整个 class 进行批量重偏向。
  
• 每个 class 都会有 markword，当处于偏向锁状态时，markword 会有 epoch 属性，当创建该 class 的实例对象时，实例对象的 epoch 值会赋值为 class 的 epoch 值，也就是说正常情况下，实例对象的 epoch 和 class 的 epoch 是相等的。
  
• 而当发生批量重偏向时，epoch 就派上用场了。
  
• 当发生批量重偏向时，首先会将 class 的 epoch 值+1，接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，将其 epoch 值修改为新值。
  
• 而那些当前没有被任何线程持有的锁实例对象，其 epoch 值则没有得到更新，此时会比 class 的 epoch 值小1。在下一次其他线程准备获取该锁对象的时候，不会因为该锁对象的线程ID不为0（也就是曾经被其他线程获取过），而直接升级为轻量级锁，而是使用 CAS 来尝试获取偏向锁，从而达到批量重偏向的优化效果。
  
• PS：对应了加锁流程图中的 “锁对象的epoch等于class的epoch？” 的选择框。
  

• 批量撤销

• 批量撤销是批量重偏向的后续流程，同样是以 class 为粒度，同样使用偏向撤销计数器。
  
• 当批量重偏向后，每次进行偏向撤销时，会计算本次撤销时间和上一次撤销时间的间隔，如果两次撤销时间的间隔超过指定时间（25秒），则此时 JVM 会认为批量重偏向是有效果的，因为此时偏向撤销的频率很低，所以会将偏向撤销计数器重置为0。
  
• 而当批量重偏向后，偏向计数器的值继续快速增加，当计数器的值超过批量撤销的阈值（默认40）时，JVM 认为该 class 的实例对象存在明显的锁竞争，不适合使用偏向锁，则会触发批量撤销操作。
  
• 批量撤销：

• 将 class 的 markword 修改为不可偏向无锁状态，也就是偏向标记位为0，锁标记位为01。接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，执行偏向锁的撤销操作。
  
• 这样当线程后续尝试获取该 class 的锁实例对象时，会发现锁对象的 class 的 markword 不是偏向锁状态，知道该 class 已经被禁用偏向锁，从而直接进入轻量级锁流程。
  
• PS：对应了加锁流程图中的 “锁对象的class是否为偏向模式？” 的选择框。
  

3.13、轻量级锁流程？

加锁流程：

• 如果关闭偏向锁，或者偏向锁升级，则会进入轻量级锁加锁流程。
  
• 1）从当前线程的栈帧中寻找一个空闲的 Lock Record，obj 属性指向锁对象。
  
• 2）将锁对象的 markword 修改为无锁状态，填充到 Lock Rrcord 的 displaced_header 属性。
  
• 3）使用 CAS 将对象头的 markword 修改为指向 Lock Record 的指针
  
• 此时的线程栈和锁对象的关系如下图所示，可以看到2次锁重入的 displaced_header 填充的是 null
  
  

解锁流程：

• 1）将 obj 属性赋值为 null。
• 2）使用 CAS 将 displaced_header 属性暂存的 displaced mark word 还原回锁对象的 markword。

3.14、重量级锁流程？

加锁流程：

• 当轻量级锁出现竞争时，会膨胀成重量级锁。
  
• 1）分配一个 ObjectMonitor，并填充相关属性。
  
• 2）将锁对象的 markword 修改为：该 ObjctMonitor 地址 + 重量级锁标记位（10）
  
• 3）尝试获取锁，如果失败了则尝试自旋获取锁
  
• 4）如果多次尝试后还是失败，则将该线程封装成 ObjectWaiter，插入到 cxq 链表中，当前线程进入阻塞状态
  
• 5）当其他锁释放时，会唤醒链表中的节点，被唤醒的节点会再次尝试获取锁，获取成功后，将自己从 cxq（EntryList）链表中移除
  
• 此时的线程栈、锁对象、ObjectMonitor 之间的关系如下图所示：
  
  ObjectMonitor 的核心属性如下：
  

ObjectMonitor() {
    _header       = NULL; // 锁对象的原始对象头
    _count        = 0;    // 抢占该锁的线程数，_count大约等于 _WaitSet线程数 + _EntryList线程数
    _waiters      = 0,    // 调用wait方法后的等待线程数
    _recursions   = 0;    // 锁的重入数
    _object       = NULL; // 指向锁对象指针
    _owner        = NULL; // 当前持有锁的线程
    _WaitSet      = NULL; // 存放调用wait()方法的线程
    _WaitSetLock  = 0 ;   // 操作_WaitSet链表的锁
    _Responsible  = NULL ;
    _succ         = NULL ;  // 假定继承人
    _cxq          = NULL ;  // 等待获取锁的线程链表，竞争锁失败后会被先放到cxq链表，之后再进入_EntryList链接
    FreeNext      = NULL ;  // 指向下一个空闲的ObjectMonitor
    _EntryList    = NULL ;  // 等待获取锁的线程链表，该链表的头结点是获取锁的第一候选者
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ; // 标记_owner是指向占用当前锁的线程的指针还是BasicLock，1为线程，0为BasicLock，发生在轻锁升级重锁的时候
    _previous_owner_tid = 0;  // 监视器上一个所有者的线程id
}

解锁流程：

• 1）将重入计数器-1，ObjectMonitor 里的 _recursions 属性。
• 2）先释放锁，将锁的持有者 owner 属性赋值为 null，此时其他线程已经可以获取到锁，例如自旋的线程。
• 3）从 EntryList 或 cxq 链表中唤醒下一个线程节点。

3.15、_cxq 链表和 _EntryList 链表的排队策略？

上文说道，“_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表”，那到底是什么时刻了？

• 通常来说，可以认为是在持有锁的线程释放锁时，该线程需要去唤醒链表中的下一个线程节点，此时如果检查到 _EntryList 为空，并且 _cxq 不为空时，会将 _cxq 链表的节点转移到 _EntryList 中。
  
• 不过也不全是这样，_cxq 链表和 _EntryList 链表的排队策略的排队策略（QMode）和执行顺序如下：

• 1）当 QMode = 2 时，此时 _cxq 比 EntryList 优先级更高，如果此时 _cxq 不为空，则会首先唤醒 _cxq 链表的头结点。除了 QMode = 2 之外，其他模式都是唤醒 _EntryList 的头结点。
• 2）当 QMode = 3 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的末尾。
• 3）当 QMode = 4 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的头部。
• 4）执行到这边，如果 _EntryList 不为空，则直接唤醒 _EntryList 的头结点并返回，如果此时 _EntryList 为空，则继续执行。
• 5）执行到这边，代表此时 _EntryList 为空。
• 6）当 QMode = 1 时，将 _cxq 链表的节点转移到 _EntryList 中，并且调换顺序，也就是原来在_cxq 头部，会变到 _EntryList 尾部。
• 7）剩余情况，将 _cxq 链表的节点转移到 _EntryList 中，并且节点顺序一致。
• 8）如果此时 _EntryList 不为空，则唤醒 _EntryList 的头结点。

4、CAS乐观锁（非阻塞算法）

CAS（Compare-and-Swap），即比较并替换，是一种实现并发算法时常用到的技术，Java并发包中的很多类都使用了CAS技术。CAS也是现在面试经常问的问题，本文将深入的介绍CAS的原理

4.1、CAS问题背景案例

介绍CAS之前，我们先来看一个例子。

import java.util.concurrent.CountDownLatch;
public class VolatileTest {
    // volatile 保障内存可见性
    public static volatile int race = 0;
    private static final int THREADS_COUNT = 20;
    private static CountDownLatch countDownLatch = new CountDownLatch(THREADS_COUNT);
  // 非原子性
    public static void increase() {
        race++;
    }
    public static void main(String[] args) throws InterruptedException {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < THREADS_COUNT; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                    countDownLatch.countDown();
                }
            });
            threads[i].start();
        }
        countDownLatch.await();
        System.out.println(race);
    }
}

• CAS是整个并发包的基础 Atimic原子类/ReentrantLock/AQS底层都是CAS
• 上面这个例子在volatile关键字详解文中用过，我们知道，运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字。

• JUC第五讲：volatile关键字详解

• 通过分析字节码我们知道，这是因为volatile只能保证可见性，无法保证原子性，而自增操作并不是一个原子操作（如下图所示），在并发的情况下，putstatic指令可能把较小的race值同步回主内存之中，导致我们每次都无法获得想要的结果。那么，应该怎么解决这个问题了？
• 

解决方法：

• 首先我们想到的是用synchronized来修饰increase方法。

public static synchronized void increase() {
    // 非原子操作，取值，加一，写值
    race++
}

• 使用synchronized修饰后，increase方法变成了一个原子操作，因此是肯定能得到正确的结果。但是，我们知道，每次自增都进行加锁，性能可能会稍微差了点，有更好的方案吗？

• 答案当然是有的，这个时候我们可以使用Java并发包原子操作类（Atomic开头），例如以下代码。

public static AtomicInteger race = new AtomicInteger(0);
public static synchronized void increase() {
  // 原子操作
  race.getAndIncrement();
}

• 我们将例子中的代码稍做修改：race改成使用AtomicInteger定义，“race++”改成使用“race.getAndIncrement()”，AtomicInteger.getAndIncrement() 是原子操作，因此我们可以确保每次都可以获得正确的结果，并且在性能上有不错的提升。

通过方法调用，我们可以发现，getAndIncrement方法调用getAndAddInt方法，最后调用的是compareAndSwapInt方法，即本文的主角CAS，接下来我们开始介绍CAS。

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}
public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
      // 拿到内存位置的最新值
        v = this.getIntVolatile(o, offset);
    } while(!this.compareAndSwapInt(o, offset, v, v + delta)); // CAS修改成功才跳出循环
    return var5;
}

• getAndAddInt 方法解析：拿到内存位置的最新值v，使用CAS尝试修将内存位置的值修改为目标值v+delta，如果修改失败，则获取该内存位置的新值v，然后继续尝试，直至修改成功

4.2、CAS原理分析

• CAS：是一种硬件对并发的支持，用于管理对共享数据的访问。相当于是无锁的非阻塞实现。多数处理器都都实现了一个CAS指令，实现“Compare And Swap”的语义，

• CAS包含3个操作数：内存值V，旧的预估值A，即将被更新的目标值B，当且仅当内存值V等于旧的预估值A，将内存地址V的值修改为B；否则，不做任何操作。
• CAS原理：通过unsafe类的compareAndSwap(JNI, Java Native Interface)方法实现的，

• 该方法包括四个参数：第一个参数是要修改的对象，第二个参数是对象中要修改变量的偏移量，第三个参数是修改之前的值，第四个参数是预想修改后的值
• 源码如下所示：
  
• 可以看到调用了“Atomic::cmpxchg”方法，“Atomic::cmpxchg”方法在linux_x86和windows_x86的实现如下。
• Linux_x86的实现
• 
• windows_x86的实现：
• 
• Atomic::cmpxchg方法解析：

• 1、mp是“os::is_MP()”的返回结果，“os::is_MP()”是一个内联函数，用来判断当前系统是否为多处理器。
• 2、如果当前系统是多处理器，该函数返回1。否则，返回0。
• 3、LOCK_IF_MP(mp)会根据mp的值来决定是否为cmpxchg指令添加lock前缀。
• 4、如果通过mp判断当前系统是多处理器（即mp值为1），则为cmpxchg指令添加lock前缀。否则，不加lock前缀。

• 这是一种优化手段，认为单处理器的环境没有必要添加lock前缀，只有在多核情况下才会添加lock前缀，因为lock会导致性能下降。cmpxchg是汇编指令，作用是比较并交换操作数。

• intel手册对lock前缀的说明如下：

• 1、确保对内存的读-改-写操作原子执行。

• 1、在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。
• 2、从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。

• 2、禁止该指令与之前和之后的读和写指令重排序。
• 3、把写缓冲区中的所有数据刷新到内存中。

• 上面的第1点保证了CAS操作是一个原子操作，第2点和第3点所具有的内存屏障效果，保证了CAS同时具有volatile读和volatile写的内存语义。

4.3、CAS乐观锁的缺点

• CAS乐观锁的缺点三大问题：
• ABA问题
• 循环时间长开销大
• 只能保证一个共享变量的原子操作

4.3.1、什么是ABA问题？ABA问题怎么解决？

• CAS 的使用流程通常如下：

• 1）首先从地址 V 读取值 A；
• 2）根据 A 计算目标值 B；
• 3）通过 CAS 以原子的方式将地址 V 中的值从 A 修改为 B。

• 但是在第1步中读取的值是A，并且在第3步修改成功了，我们就能说它的值在第1步和第3步之间没有被其他线程改变过了吗？
  
• CAS操作的“ABA”问题

• 如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA”问题

• 如何解决ABA问题

• 使用版本号(在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A)
• Java并发包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。因此，在使用CAS前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效

4.3.2、循环时间长开销很大

• CAS 通常是配合无限循环一起使用的，我们可以看到 getAndAddInt 方法执行时，如果 CAS 失败，会一直进行尝试。
• 不适用于竞争激烈的情形中：并发越高，失败的次数会越多，CAS如果长时间不成功，会极大的增加CPU的开销。因此CAS不适合竞争十分频繁的场景

4.3.3、只能保证一个变量的原子操作

• 只能保证一个共享变量的原子操作：对多个共享变量操作时，循环CAS就无法保证操作的原子性
• 通过以下两种办法来解决：

• 1、多个变量放在一个对象里来进行CAS操作，通过 AtomicReference 来保证原子性；
• 2、使用互斥锁来保证原子性；

4.3、CAS在业务场景的使用

• 1、CAS自旋volatile变量，是一种很经典的用法（AQS）
• 2、在数据库产品中，为保证索引的一致性，一个常见的选择是，保证只有一个线程能够排他性地修改一个索引分区，如何在数据库抽象层面实现呢？

• 可以考虑为索引分区对象添加一个逻辑上的锁，例如，以当前独占的线程ID作为锁的数值，然后通过原子操作设置lock数值，来实现加锁和释放锁

public class AtomicBTreePartition {
        private volatile long lock;
    public void acquireLock(){}
    public void releaseeLock(){}
}

• 那么在Java代码中，我们怎么实现锁操作呢？
• 目前Java提供了两种公共API，可以实现这种CAS操作，比如使用java.util.concurrent.atomic.AtomicLongFieldUpdater，它是基于反射机制创建，我们需要保证类型和字段名称正确

private static fnal AtomicLongFieldUpdater<AtomicBTreePartition> lockFieldUpdater = AtomicLongFieldUpdater.newUpdater(AtomicBTreePartition.class, "lock");
private void acquireLock(){
    long t = Thread.currentThread().getId();
    while (!lockFieldUpdater.compareAndSet(this, 0L, t)){
        // 等待一会儿，数据库操作可能比较慢
        …
    }
}

5、AQS原理详解 20190106

• 数据结构：state、阻塞队列、双链表、线程封装成Node

• state实现独占；双向链表、Node.Sharead实现共享

非公平锁（可以控制公平性）

• ReentrantLock fairLock = new ReentrantLock(true);//当公平性为真时，会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”情况发生的一个办法
• 建议：只有当你的程序确实有公平性需求时，才有必要指定它
• 特性锁
• 可重入：直到state(表示同步状态)为0，其他锁才可以用（线程自己是可以重复获取此锁的（state会累加））
• 对锁获取粒度的一个概念：当一个线程视图获取一个它已经获取的锁时，这个获取动作就自动成功。
• 轮询：用tryLock(long timeout, TimeUnit unit)和tryLock() 这两个方法实现
• 定时：指的是在指定时间内没有获取到锁，就取消阻塞并返回获取锁失败
• 可中断：lockInterruptibly，防止死锁

注意事项：

1、在finally中释放锁，目的是保证在获取锁之后，最终能够被释放；

2、不要将获取锁的过程卸载try块中，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故被释放

3、reentrantLock提供了一个newCondition方法，以便用户在同一把锁的情况下，可以根据不同的情况执行等待或唤醒动作

• 锁的更细粒度的使用：

• ReentrantReadWriteLock/StampedLock //适用于当数据量较大，并发读多、并发写少的时候

Action1：AQS中有多个线程并发添加到队列中，需要做并发控制吗

这个是需要的，源码中是通过 CAS 来进行并发控制。

• 在 addWaiter(Node mode) 方法中，如果并发添加节点，则只会有一个线程成功，另一个会失败，从而走到 enq(node) 方法中去进行重试。
  
• 说实话，虽然看过源码，但是真的很难记得这么多细节，因为 Java 面试要准备的东西实在太多了，所以这边可以利用一个小技巧。
  
• 小技巧：首先并发控制肯定是要做的，这个不难推测；接着，如果注意观察的话，不难发现在 JDK 源码中做并发控制的方式大多是 CAS，所以当你不知道怎么做并发控制的时候，可以直接蒙个 CAS，很有可能就被你蒙对了。