ReentrantLock（AQS），Volatile，Synchronized的实现原理

心已赠人 2023-03-01 13:52 4阅读 0赞

本文参考：

[JUC学习（八）：AQS的CLH队列][JUC_AQS_CLH]  
[并发编程——详解 AQS CLH 锁][AQS CLH]  
[JMM和底层实现原理][JMM]

> AQS

ReentrantLock类关于lock接口的操作都交给了**内部类Sync类**来实现，**Sync类又有两个子类`NonFairSync(`不公平锁`)，FairSync(`公平锁`).`**

abstract static class Sync extends AbstractQueuedSynchronizer
    static final class NonfairSync extends Sync
    static final class FairSync extends Sync

AQS重要成员变量

private transient volatile Node tail;  //  CLH队列
        private volatile int state;    //  锁的状态

AQS使用的设计模式：

`模板方法设计模式：`定义一个代码模板结构，相同部分在父类实现，不同部分由子类实现  
[模板方法模式（Template Method） - 最易懂的设计模式解析][Template Method_ -]

安卓中的View，Activity都使用了模板方法设计模式，View类规范了所有View需要实现的行为，View的子类可以在onMeasure，onLayout，onDraw中扩展各自不同的行为；体现了设计模式的`开闭原则`  
**AQS抽象类为子类提供了tryAcquire，tryRelease去扩展自己的不同行为**

NonfairSync：

NonfairSync.lock()

final void lock() {
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    acquire(1);
            }
    
        protected final boolean compareAndSetState(int expect, int update) {
            // See below for intrinsics setup to support this
            return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
        }

首先通过CAS尝试将AQS的state由0变为1:

如果成功，说明当前锁没有被线程持有，调用setExclusiveOwnerThread() 设置当前线程持有当前锁即可；  
如果失败了, 说明当前锁被持有，调用acquire（1）；

acquire()

public final void acquire(int arg) {
            if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
                selfInterrupt();
        }

在acquire() 中，首先调用了tryAcquire() 尝试获取

NonFairSync的tryAcquire的实现

final boolean nonfairTryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) {
                    if (compareAndSetState(0, acquires)) {
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0) // overflow
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }

首先判断AQS的state是否为0，如果是0，则当前锁未被持有，设置当前线程即可，如果不为0，说明当前锁被持有，并且有另一个线程尝试进入，则将AQS的state+1（类似synchronized的monitor的进入数）；

addWaiter（）

private Node addWaiter(Node mode) {
            Node node = new Node(Thread.currentThread(), mode);
            // Try the fast path of enq; backup to full enq on failure
            Node pred = tail;
            if (pred != null) {
                node.prev = pred;
                if (compareAndSetTail(pred, node)) {
                    pred.next = node;
                    return node;
                }
            }
            enq(node);
            return node;
        }

addWaiter的作用是将为获得锁被阻塞的线程打包成Node添加到tail链表（队列）中保存起来，添加链表节点的过程使用了CAS添加；

![format_png][]

UnFairSync lock

**回顾一下UnFairSync的lock（）过程：**首先尝试通过CAS将锁的状态（AQS的state）由0变为1；如果成功说明锁未被持有，设置当前线程持有即可，如果失败，说明锁已经被持有，调用acquire（1）；在acquire（）中，`1`首先调用tryAcquire（）再次尝试获取锁，如果失败将锁的state+1，`2`其次调用addWaiter（）将当前线程包装成Node放入等待队列`AQS的tail`中，`3`调用当线程的interrupt（）尝试中断；

unLock（）：

public void unlock() {
            sync.release(1);
        }
    
        public final boolean release(int arg) {
            if (tryRelease(arg)) {
                Node h = head;
                if (h != null && h.waitStatus != 0)
                    unparkSuccessor(h);
                return true;
            }
            return false;
        }
    
            protected final boolean tryRelease(int releases) {
                int c = getState() - releases;
                if (Thread.currentThread() != getExclusiveOwnerThread())
                    throw new IllegalMonitorStateException();
                boolean free = false;
                if (c == 0) {
                    free = true;
                    setExclusiveOwnerThread(null);
                }
                setState(c);
                return free;
            }

unLock()做的事情：将锁的state-1，如果state==0了，在等待队列中唤醒一个线程；

> 公平锁和不公平锁的区别：

FairLock.lock（）

final void lock() {
                acquire(1);
            }

公平锁的lock方法是直接调用acquire（）；

tryAcquire的实现：

/**
             * Performs non-fair tryLock.  tryAcquire is implemented in
             * subclasses, but both need nonfair try for trylock method.
             */
            final boolean nonfairTryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) {
                    if (compareAndSetState(0, acquires)) {
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0) // overflow
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }
            /**
             * Fair version of tryAcquire.  Don't grant access unless
             * recursive call or no waiters or is first.
             */
            protected final boolean tryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) {
                    if (!hasQueuedPredecessors() &&
                        compareAndSetState(0, acquires)) {
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0)
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }

在调用tryAcquire（）尝试获取锁时，公平和不公平锁的实现稍微不同，公平锁会在state == 0的时候直接设置当前线程去持有锁，而非公平锁会调用`hasQueuedPredecessors()`去判断tail等待队列中有没有比当前线程等待时间更长的线程，如果有，就不会设置当前线程去持有锁；

> AQS内部的CLH自旋锁

CLH是一个基于链表（队列）的自旋（公平）锁，每一个等待锁的线程封装成节点，不断自旋判断前一个节点的状态，如果前一个节点释放锁就结束自旋；

AQS的CLH队列`tail`对CLH自旋锁进行了两个方面改进：

*  `节点的结构：`AQS中的CLH队列的节点采用双向链表
 *  `节点等待机制:`传统的CLH是通过不断自旋判断前一个节点的状态，AQS改成了自旋+阻塞+唤醒，线程在经过几次自旋后会进入阻塞状态等待唤醒，唤醒后继续自旋，等待前一个线程释放锁，兼顾了性能和效率；

> 可重入锁的实现：

`可重入锁：指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞`

*  在 tryAcquire()中判断是否是当前线程持有，如果是则将state通过CAS +1；
 *  在释放锁时，只有state为0时，锁才会正真释放，可以被其他线程持有；

> JMM `JAVA Memory Model`

**JVM定义了JMM用来屏蔽各种硬件和操作系统的内存访问差异，即JMM的主要目标是定义程序中各个变量的访问规则；**

![format_png 1][]

JMM规定了所有的变量都存放在主内存，每个线程有自己的工作内存，工作内存中保存着主内存变量的副本，线程对变量的访问只能通过自己的工作内存的副本访问，每个线程只能访问自己的工作线程；

内存间交互操作：

JMM定义了8种原子操作用来实现主内存到工作内存的拷贝，工作内存到主内存的同步：

*  `lock 锁定:`作用于主内存 ，将主内存的一个变量标识为一个线程独占
 *  `unlock 解锁:`作用于主内存，把主内存中一个处于被线程独占的变量释放出来
 *  `read 读取:`作用于主内存，把主内存的变量传入到工作内存，配合load使用
 *  `load 载入:`作用于工作内存，配合read将主内存的值放入工作内存的副本中
 *  `use 使用:`作用于工作内存，当虚拟机遇到一个需要使用这个变量的字节码指令时，将工作内存变量的值传递给执行引擎
 *  `assign 赋值：`作用于工作内存，当虚拟机遇到一个需要给变量赋值的字节码指令时，从执行引擎接收新的值传入工作内存
 *  `store 存储：`作用于工作内存，将工作内存的一个变量传递给主内存，配合write使用
 *  `write 写入：`作用于主内存，配合store将工作内存副本的值在主内存更新

Volatile：

被volatile修饰的变量具有`可见性，有序性`，保证单个变量的读写的`原子性`(i++不保证)

volatile原理：

*  被volatile修饰的变量会存在一个`lock前缀`，lock前缀的作用是将当前线程的工作内存中副本值直接写入主内存，并且将其他工作内存的值失效（立刻执行store，write操作）；**强制刷新变量，保证可见性；**
 *  lock前缀还有一个功能：`内存屏障`（重排序不能在内存屏障前执行），**抑制重排序，保证有序性；**

happen-before：先行发生原则

如果操作1 happen-before 操作2，那么操作1 的结果对 操作2 是可见的（仅要求可见性，不要求有序性，可以重排序）；

*  volatile规定了变量的写 happen-before 变量的读；

# Synchronized原理： #

每一个对象都会有一个monitor，monitor是由C++实现的一个ObjectMonitor类，可以理解为一个实现线程同步的对象；

Monitor的属性

*  当多个线程同时访问同步代码块时，会先将线程放入`EntryList`中，当一个线程持有monitor对象后，会`count++`，设置`owner`为此线程；
 *  如果`owner`调用wait（）或者同步任务完成，就会将`count--`，`owner`设置为null，并且将这个线程放入`WaitSet`，等待下一次被唤醒

monitorenter:

遇到monitorenter指令会尝试获取monitor对象，通过判断monitor对象的count是否为0，如果count = 0，当前线程就持有锁，count++，如果不会零，就阻塞，如果持有锁的线程重新进入锁，count继续++；

monitorexit：

执行exit指令的线程必须是锁的持有者，执行完exit后，monitor的count--，如果count == 0，则退出锁，被阻塞的线程可以尝试获取锁；

同步代码块时通过enter/exit字节码指令实现的，如果是同步方法，就会在方法的字节码加入一个`ACC_SYNCHRONIZED`的flag，如果有这个flag，表明这是一个同步方法，线程在执行时会尝试获取Monitor对象（静态方法是类的Monitor，非静态方法则是实例对象的Monitor），本质上和enter、exit一样都是通过Monitor对象来实现的；

synchronized优化：

在早期的版本中，使用synchronized关键字加锁都会将拿不到锁的线程进行阻塞，需要上下文切换，效率较低，在jdk1.6以后对synchronized锁进行了优化；

*  `锁消除：`在代码上加了锁，但是虚拟机判断出这一块代码不可能被多线程竞争，就会把这个锁消除掉；虚拟机判断的依据是**逃逸分析**

逃逸分析：

分析对象的动态作用域，当一个对象在方法中被定义后，它可能被外部其他方法访问（作为参数传入），这种称为方法逃逸，如果被其他线程访问，称为线程逃逸，如果能证明这个对象不会逃逸到其他方法或者线程，虚拟机会对它做一些优化：

1.  **栈上分配：**对象的内存存放在栈帧中而不是堆上；
2.  **同步消除：**锁消除
3.  **标量替换：*****标量：***一个数据无法分解成更小的数据，比如java原始类型；***聚合量：***可以被分解成更小的数据，比如对象；如果逃逸分析证明这个对象不会方法逃逸，并且这个对象是聚合量，那么程序执行的时候可能不会创建这个对象，而是创建它的成员变量；

*  `锁粗化：`如果虚拟机检测到一串操作都对一个对象加锁，释放锁，将会把加锁的范围粗化到整个操作的外部；

StringBuffer stringBuffer = new StringBuffer();
            stringBuffer.append("加锁----释放锁");
            stringBuffer.append("加锁----释放锁");
            stringBuffer.append("加锁----释放锁");
    
        @Override
        public synchronized StringBuffer append(String str) {
            toStringCache = null;
            super.append(str);
            return this;
        }

上面的操作就会进行synchronized锁粗化的优化

*  `自适应自旋：`自旋时间由前一次在同一个锁的自旋时间和锁的拥有者状态来决定，如果虚拟机判断获得这个锁的可能性很大，就会增加自旋时间，如果觉得很难获得锁，可能会省去自旋这一步节约CPU；
 *  `偏向锁：`这个锁会偏向于第一个持有它的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁／解锁的一些CAS操作（比如等待队列的一些CAS操作），这种情况下，就会给线程加一个偏向锁。 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁
 *  `轻量级锁：`由偏向锁转化来，相对于传统的重量级锁，不会阻塞线程，而是通过自旋进行等待；以CPU为代价，避免线程的上下文切换，追求响应速度；`偏向锁切换到轻量级锁会Stop the World`

![format_png 2][]  
  
作者：leap\_  
链接：https://www.jianshu.com/p/485d77e19e13  
来源：简书  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[JUC_AQS_CLH]: https://links.jianshu.com/go?to=https%3A%2F%2Fblog.csdn.net%2Fu010670411%2Farticle%2Fdetails%2F87921138
[AQS CLH]: https://www.jianshu.com/p/4682a6b0802d
[JMM]: https://www.jianshu.com/p/8a58d8335270
[Template Method_ -]: https://links.jianshu.com/go?to=https%3A%2F%2Fblog.csdn.net%2Fcarson_ho%2Farticle%2Fdetails%2F54910518%3Futm_medium%3Ddistribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase%26depth_1-utm_source%3Ddistribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
[format_png]: /images/20230208/4380e27e9e484c8bb19e0277407795c4.png
[format_png 1]: /images/20230208/bece29bd28db4a9da2b3ab91b3329aea.png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzc5MDU5Mi02ZjZmMDE4ZjZmYjIzOTViLnBuZw?x-oss-process=image/format,png