深入浅出Java 锁 | 源码剖析 | 万字解析

目录

硬件内存结构&Java内存模型

硬件内存结构

Java内存模型（JMM）

JMM中三大特性：原子性、有序性、可见性

Java中有哪些锁？

Java中锁可以分成悲观锁和乐观锁的实现。

乐观锁和悲观锁的区别，乐观锁一定好嘛？

CAS 比较和交换

synchronized锁（互斥锁）

原理

对象在内存中是如何进行存储的？

synchronized锁升级

ReentrantLock（互斥锁）

tips：如果竞争比较激烈，推荐lock锁，效率更高；如果几乎没有竞争，推荐synchronized

基本写法

启动源码分析！

lock方法

tryAcquire方法，尝试获取锁资源

addWaiter方法

acquireQueued方法

unlock方法

为什么唤醒线程时，为啥从尾部往前找？

延伸问题：AQS是什么？【AbstractQueuedSynchronizer】

ReentrantReadWriteLock（读写锁）

发展的产物

启动源码！

写锁——lock方法

写锁——tryAcquire方法

写锁——unlock方法

读锁——lock方法

加锁-扔到队列准备阻塞操作

---

硬件内存结构&Java内存模型

硬件内存结构

处理器和计算机存储设备之间运算速度相差几个数量级，为了达到“高并发”的效果，在处理器和内存之间加了高速缓存“Cache”。

将运算需要使用的数据复制到缓存中，让运算能够快速进行，当运算完成后，再将缓存中的结果写入主内存中，这样运算器就不用等待主内存的读写操作。 每个处理器都有自己的高速缓存，同时又共同操作同一块主存，当多个处理器同时操作主存时，可能导致数据不一致，因此需要“缓存一致性协议”保障。

Java内存模型（JMM）

说白了，就是CPU内存和JVM内存之间的一个规范，这个规范可以将JVM的字节码指令转换为CPU能够识别的一些指令。

比如在×86的CPU中，原子性的保证要基于cmpxchg（Compare And Exchange）去实现，但是其他的CPU型号各自不同，在JMM中，就会将涉及到的CAS操作根据不同的CPU情况去翻译成不同的指令。

Java内存模型简称JMM（Java Memory Model），用来屏蔽各种硬件和操作系统的内存访问差异，实现让Java程序在各平台下都能够达到一致的内存访问效果。

JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存，每个线程都有一个私有的本地内存，本地内存存储了该线程读写变量的副本。

主内存（JVM）：主要存储Java实例对象，所有线程创建的实例对象都存放在主存中，不管该实例对象是成员变量还是方法中的局部变量，当然也包括共享的类信息、常量、静态变量。共享数据区域，多个线程对同一个变量访问可能会出现线程安全问题。

工作内存：主要存储当前方法的所有本地变量信息，每个线程只能访问自己的工作内存，即线程中的本地变量对其他线程是不可见的，由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题，例如ThreadLocal。

JMM中三大特性：原子性、有序性、可见性

这里跟MySQL中区分开哦~点击查看MySQL中事务与锁

并发编程原子性：事务是一个最小的执行的单位，一次事务的多次操作要么都成功，要么都失败。在JMM层面，指一个或多个指令在CPU中执行过程中不允许中断。

有序性：指令在CPU调度执行时，CPU会为了提升执行效率，在不影响结果的前提下，对CPU指令进行重新排序。

如果不希望CPU对指令进行重排序，可以追加volatile属性进行修饰，就不会对当前属性进行指令重排序。

正常顺序是申请内存，初始化，关联，如果CPU对指令重排，可能会造成申请内存，关联，初始化，在还没有初始化时，其他线程来获取数据，导致获取到的数据虽然有地址引用，但是内部的数据还没初始化，都是默认值，导致使用时，可能出现与预期不符的结果。

案例——单例模式中双重校验方式，点击查看博客内容~

可见性：线程之间是隔离的，线程拿到的是主存变量的副本，更改变量需要刷新回主存，其他线程需要从主存重新获取才能拿到变更的值。

Java中有哪些锁？

Java中锁可以分成悲观锁和乐观锁的实现。

乐观锁和悲观锁是俩概念，不是单独指定/指代某个锁。

Java中对这俩种概念做了具体的落地。

• 乐观锁：认为在操作的时候，没有线程与我并打操作，正常的写，但是有并发就会失败，返回flase，成功则返回true；不会阻塞，会等待、失败再试······

• 悲观锁：认为在操作的时候，有线程和我并发操作，就先尝试竞争锁资源，如果拿不到这个锁，就将线程挂起，阻塞等待。

• 乐观锁：CAS

• 悲观锁：synchronized、Lock锁

乐观锁和悲观锁的区别，乐观锁一定好嘛？

乐观锁不会让你的 线程阻塞、挂起 ，可以让CPU一直调度执行竞争这个乐观锁，可以直到成功为止。

悲观锁会在竞争锁资源失败后，直接 挂起、阻塞线程 ，等到锁资源释放后，才可能唤醒这个线程再去竞争锁资源。

核心区别就是 是否会挂起线程 ，因为挂起线程这个操作，线程在用户态时不能这么做，需要从用户态转换到内核态，让OS操作系统去唤醒挂起的线程，这个用户态和内核态的切换就比较耗时。

这么看乐观锁相对悲观锁有一定的优势，但是也不是所有场景都ok。

如果竞争很激烈，导致乐观锁一直失败，那CPU就需要一直去调度他，但是又一直失败，就会有点浪费CPU的资源了。会导致CPU占用率飙高······

在操作系统下，线程就一个阻塞状态BLOCKED，Java中为了更好的排查问题，给线程提供了三种阻塞的状态，BLOCKED，WAITING，TIMED_WAITING……

CAS 比较和交换

线程基于CAS修改数据的方式：先从主内存数据，在修改之前比较数据是否一致，如果一致修改主内存数据，如果不一致，放弃修改。可以认为CAS就是比较和交换，而比较与交换 这个是原子操作。

CAS在Java层面就是Unsafe类中提供的一个native方法，这个方法只提供了CAS成功返回true，失败返回false，如果需要重试策略，自己实现。

CAS的几个点：

• CAS只能对一个变量的修改实现原子性

• CAS可能存在ABA问题

  • A线程修改主内存数据从1-2，卡在获取1之后；B线程修改从1-2，√；C线程修改从2-1，√；A执行CAS操作，发现主内存是1，直接修改。但是此1非彼1呀！

• 在CAS执行次数过多时候，依旧无法实现数据修改，CPU会一直调度这个线程，造成对CPU性能损耗。【乐观锁】

  • synchronized的实现方式是CAS自旋一定次数以后，如果还不行就挂起线程

  • LongAdder的实现方式：当CAS失败后，将操作的值，存储起来到本地线程，先不共享变量，后续一起添加

• 在多核情况下，有lock指令保证只有一个线程在执行当前CAS

synchronized锁（互斥锁）

synchronized锁可以给方法、代码块加锁

• 类锁：基础当前类的Class加锁

• 对象锁：基于this对象加锁

synchronized是互斥锁，每个线程获取synchronized时，基于synchronized绑定的对象去获取锁！

synchronized锁是基于对象实现的！

原理

对象在内存中是如何进行存储的？

synchronized锁升级

synchronized在jdk1.6之前，一直是重量级锁：只要线程获取锁资源失败，直接挂起线程（用户态到内核态的转换）

在jdk1.6之前synchronized效率贼低，再加上Doug Lea推出了ReentrantLock，效率比synchronized快多了，导致JDK团队不得不在jdk1.6将synchronized做优化

锁升级：

• 无锁状态、匿名偏向状态：没有线程拿锁。

• 偏向锁状态：没有线程的竞争，只有一个线程再获取锁资源。 线程竞争锁资源时，发现当前synchronized没有线程占用锁资源，并且锁是偏向锁，使用CAS的方式，设置o的线程ID为当前线程，获取到锁资源，下次当前线程再次获取时，只需要判断是偏向锁，并且线程ID是当前线程ID即可，直接获得到锁资源。

  • 查看对象头中的MarkWord里的线程ID，是否是当前线程，如果不是，就CAS尝试改，如果是，就拿到了锁资源。

• 轻量级锁：偏向锁出现竞争时，会升级到轻量级锁（触发偏向锁撤销）。 轻量级锁的状态下，线程会基于CAS的方式，尝试获取锁资源，CAS的次数是基于自适应自旋锁实现的，JVM会自动的基于上一次获取锁是否成功，来决定这次获取锁资源要CAS多少次。

  • 查看对象头中的MarkWord里的Lock Record指针指向的是否是当前线程的虚拟机栈，如果是，拿锁执行业务，如果不是CAS，尝试修改，修改他几次，不成，再升级到重量级锁。

• 重量级锁：轻量级锁CAS一段次数后，没有拿到锁资源，升级为重量级锁（其实CAS操作是在重量级锁时执行的）。 重量级锁就是线程拿不到锁，就挂起。

  • 查看对象头中的MarkWord里的指向的ObjectMonitor，查看owner是否是当前线程，如果不是，扔到ObjectMonitor里的EntryList中，排队，并挂起线程，等待被唤醒。

偏向锁是延迟开启的，并且在开启偏向锁之后，默认不存在无锁状态，只存在匿名偏向synchronized因为不存在从重量级锁降级到偏向或者是轻量。

synchronized在偏向锁升级到轻量锁时，会涉及到偏向锁撤销，需要等到一个安全点，stw，才可以撤销，并发偏向锁撤销比较消耗资源 在程序启动时，偏向锁有一个延迟开启的操作，因为项目启动时，ClassLoader会加载.class文件，这里会涉及到synchronized操作， 为了避免启动时，涉及到偏向锁撤销，导致启动效率变慢，所以程序启动时，默认不是开启偏向锁的。 如果在开启偏向锁的情况下，查看对象，默认对象是匿名偏向。

编译器优化的结果，出现了下列效果

锁消除：线程在执行一段synchronized代码块时，发现没有共享数据的操作，自动帮你把synchronized去掉。

锁膨胀：在一个多次循环的操作中频繁的获取和释放锁资源，synchronized在编译时，可能会优化到循环外部。

偏向锁会降级到无锁状态吗？会，当偏向锁状态下，获取当前对象的hashcode值，会因为对象头空间无法存储hashcode，导致降级到无锁状态。

ReentrantLock（互斥锁）

tips：如果竞争比较激烈，推荐lock锁，效率更高；如果几乎没有竞争，推荐synchronized

原因：synchronized只有锁升级，当升级到重量级锁后，无法降级到轻量级、偏向锁。

lock锁的使用相对synchronized成本更高。

synchronized是非公平锁，lock是公平+非公平锁

lock锁提供的功能更完善，lock可以使用tryLock指定等待锁的时间

lock锁还提供了lockInterruptibly允许线程在获取锁的期间被中断。

synchronized基于对象实现，lock锁基于AQS+CAS实现

基本写法

public static void main(String[] args) {ReentrantLock lock = new ReentrantLock();lock.lock();try{// 业务代码}finally{lock.unlock();}
}

启动源码分析！

那当然是看lock方法啦，lock方法是如何让当前线程获取到锁资源的？

先区分个概念

• 公平锁

• 非公平锁

lock方法

// 公平锁 FairSync sync的lock方法
final void lock() {acquire(1);
}// 非公平锁 NonfairSync sync的lock方法
final void lock() {if (compareAndSetState(0, 1))setExclusiveOwnerThread(Thread.currentThread());elseacquire(1);
}

// 无论公平还是非公平，都会走这里，我们可以认为他是核心
// arg = 1 
public final void acquire(int arg) {// 1 调用tryAcquire方法：尝试获取锁资源；拿到锁资源就返回true，结束。如果没有拿到锁资源 if (!tryAcquire(arg) &&// 2 执行后面的方法，先addWaiter方法：将没有获取到锁资源的线程封装为Node对象。// 并且插入到AQS队列的尾部。作为tail// 3 调用acquireQueued方法：查看当前排队的Node节点，是否在队列的前面，如果在前面【head.next】，尝试获取锁资源// 如果不在前面，就尝试将线程挂起，阻塞起来acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt();
}

tryAcquire方法，尝试获取锁资源

公平锁情况：

// 公平锁  acquires = args = 1
protected final boolean tryAcquire(int acquires) {// 拿到当前线程final Thread current = Thread.currentThread();// 拿到AQS的stateint c = getState();// 如果state == 0，说明没有线程占用着当前的锁资源if (c == 0) {// 判断是否有线程在排队，如果有线程排队，返回true，配上前面的!，那会直接不执行返回最外层的falseif (!hasQueuedPredecessors() &&// 如果没有线程排队，直接CAS尝试获取锁资源compareAndSetState(0, acquires)) {// 将当前占用这个互斥锁的线程属性设置为当前线程setExclusiveOwnerThread(current);return true;}}// 当前state != 0，说明有线程占用着锁资源// 判断拿着锁的线程是不是当前线程（锁重入）else if (current == getExclusiveOwnerThread()) {int nextc = c + acquires;if (nextc < 0)throw new Error("Maximum lock count exceeded");// 将值设置给statesetState(nextc);// 拿锁成功return true;}return false;
}

非公平锁：

// 非公平锁实现   
final boolean nonfairTryAcquire(int acquires) {// 拿到当前线程！final Thread current = Thread.currentThread();// 拿到AQS的stateint c = getState();// 如果state == 0，说明没有线程占用着当前的锁资源if (c == 0) {// 没人占用锁资源，直接抢一波（不管有没有线程在排队）if (compareAndSetState(0, acquires)) {// 将当前占用这个互斥锁的线程属性设置为当前线程setExclusiveOwnerThread(current);// 返回true，拿锁成功return true;}}// 当前state != 0，说明有线程占用着锁资源// 判断拿着锁的线程是不是当前线程（锁重入）else if (current == getExclusiveOwnerThread()) {// 将state再次+1int nextc = c + acquires;// 锁重入是否超过最大限制// 01111111 11111111 11111111 11111111   + 1// 10000000 00000000 00000000 00000000// 抛出errorif (nextc < 0) throw new Error("Maximum lock count exceeded");// 将值设置给statesetState(nextc);// 返回true，拿锁成功return true;}return false;
}

addWaiter方法

尝试获取锁资源失败了。将当前线程封装为node对象，并且插入到AQS队列的末尾。

// 将当前线程封装为Node对象，并且插入到AQS队列的末尾
private Node addWaiter(Node mode) {// 将当前线程封装为Node对象，mode为null，代表互斥锁 Node node = new Node(Thread.currentThread(), mode);// Try the fast path of enq; backup to full enq on failure// pred是tail节点Node pred = tail;// 如果pred不为null，有线程正在排队if (pred != null) {// 将当前节点的prev，指定tail尾节点node.prev = pred;// 以CAS的方式，将当前节点变为tail节点if (compareAndSetTail(pred, node)) {// 之前的tail的next指向当前节点pred.next = node;return node;}}// 添加的流程为，  自己prev指向、tail指向自己、前节点next指向我// 如果上述方式，CAS操作失败，导致加入到AQS末尾失败，如果失败，就基于enq的方式添加到AQS队列enq(node);return node;
}// enq，无论怎样都添加进入
private Node enq(final Node node) {for (;;) {// 拿到tailNode t = tail;// 如果tail为null，说明当前没有Node在队列中if (t == null) { // 创建一个新的Node作为head，并且将tail和head指向一个Nodeif (compareAndSetHead(new Node()))tail = head;} else {// 和上述代码一致！node.prev = t;if (compareAndSetTail(t, node)) {t.next = node;return t;}}}
}

acquireQueued方法

acquireQueued方法会查看当前排队的Node是否是head的next，如果是，尝试获取锁资源，如果不是或者获取锁资源失败那么就尝试将当前Node的线程挂起（unsafe.park()）

在挂起线程前，需要确认当前节点的上一个节点的状态必须是小于等于0，

如果为1，代表是取消的节点，不能挂起

如果为-1，代表挂起当前线程如果为-2，-3，需要将状态改为-1之后，才能挂起当前线程

// acquireQueued方法
// 查看当前排队的Node是否是head的next，
// 如果是，尝试获取锁资源，
// 如果不是或者获取锁资源失败那么就尝试将当前Node的线程挂起（unsafe.park()）
final boolean acquireQueued(final Node node, int arg) {// 标识。boolean failed = true;try {// 循环走起for (;;) {// 拿到上一个节点final Node p = node.predecessor();if (p == head && // 说明当前节点是head的nexttryAcquire(arg)) { // 竞争锁资源，成功：true，失败：false// 进来说明拿到锁资源成功// 将当前节点置位head，thread和prev属性置位nullsetHead(node);// 帮助快速GCp.next = null; // 设置获取锁资源成功failed = false;// 不管线程中断。return interrupted;}// 如果不是或者获取锁资源失败,尝试将线程挂起// 第一个事情，当前节点的上一个节点的状态正常！// 第二个事情，挂起线程if (shouldParkAfterFailedAcquire(p, node) &&// 通过LockSupport将当前线程挂起parkAndCheckInterrupt())}} finally {if (failed)cancelAcquire(node);}
}// 确保上一个节点状态是正确的
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {// 拿到上一个节点的状态int ws = pred.waitStatus;// 如果上一个节点为 -1if (ws == Node.SIGNAL)// 返回true，挂起线程return true;// 如果上一个节点是取消状态if (ws > 0) {// 循环往前找，找到一个状态小于等于0的节点do {node.prev = pred = pred.prev;} while (pred.waitStatus > 0);pred.next = node;} else {// 将小于等于0的节点状态该为-1compareAndSetWaitStatus(pred, ws, Node.SIGNAL);}return false;
}

unlock方法

释放锁资源：【这里倒是部分公平还是非公平了】

• 将state-1。

• 如果state减为0了，唤醒在队列中排队的Node。（一定唤醒离head最近的）

// 真正释放锁资源的方法
public final boolean release(int arg) {// 核心的释放锁资源方法if (tryRelease(arg)) {// 释放锁资源释放干净了。  （state == 0）Node h = head;// 如果头节点不为null，并且头节点的状态不为0，唤醒排队的线程if (h != null && h.waitStatus != 0)、// 唤醒线程unparkSuccessor(h);return true;}// 释放锁成功，但是state != 0return false;
}
// 核心的释放锁资源方法
protected final boolean tryRelease(int releases) {// 获取state - 1int c = getState() - releases;// 如果释放锁的线程不是占用锁的线程，抛异常if (Thread.currentThread() != getExclusiveOwnerThread())throw new IllegalMonitorStateException();// 是否成功的将锁资源释放利索 （state == 0）boolean free = false;if (c == 0) {// 锁资源释放干净。free = true;// 将占用锁资源的属性设置为nullsetExclusiveOwnerThread(null);}// 将state赋值setState(c);// 返回true，代表释放干净了return free;
}// 唤醒节点
private void unparkSuccessor(Node node) {// 拿到头节点状态int ws = node.waitStatus;// 如果头节点状态小于0，换为0if (ws < 0)compareAndSetWaitStatus(node, ws, 0);// 拿到当前节点的nextNode s = node.next;// 如果s == null ，或者s的状态为1if (s == null || s.waitStatus > 0) {// next节点不需要唤醒，需要唤醒next的nexts = null;// 从尾部往前找，找到状态正常的节点。（小于等于0代表正常状态）for (Node t = tail; t != null && t != node; t = t.prev)if (t.waitStatus <= 0)s = t;}// 经过循环的获取，如果拿到状态正常的节点，并且不为nullif (s != null)// 唤醒线程LockSupport.unpark(s.thread);
}

为什么唤醒线程时，为啥从尾部往前找？

因为在addWaiter操作时，是先将当前Node的prev指针指向前面的节点，然后是将tail赋值给当前Node，最后才是能上一个节点的next指针，指向当前Node。

如果从前往后，通过next去找，可能会丢失某个节点，导致这个节点不会被唤醒~

如果从后往前找，肯定可以找到全部的节点。

延伸问题：AQS是什么？【AbstractQueuedSynchronizer】

AQS就是一个抽象队列同步器，abstract queued sychronizer，本质就是一个抽象类。

AQS中有一个核心属性state，其次还有一个双向链表以及一个单向链表。

首先state是基于volatile修饰，再基于CAS修改，同时可以保证三大特性。（原子，可见，有序）

其次还提供了一个双向链表。有Node对象组成的双向链表。

最后在Condition内部类中，还提供了一个由Node对象组成的单向链表。

AQS是JUC下大量工具的基础类，很多工具都基于AQS实现的，比如lock锁，CountDownLatch，Semaphore，线程池等等都用到了AQS。

---

state是啥：state就是一个int类型的数值，同步状态，至于到底是什么状态，看子类实现。

condition和单向链表？都知道sync内部提供了wait方法和notify方法的使用，lock锁也需要实现这种机制，lock锁就基于AQS内部的Condition实现了await和signal方法。（对标sync的wait和notify）

---

sync在线程持有锁时，执行wait方法，会将线程扔到WaitSet等待池中排队，等待唤醒

lcok在线程持有锁时，执行await方法，会将线程封装为Node对象，扔到Condition单向链表中，等待唤醒

---

Condition在做了什么：将持有锁的线程封装为Node扔到Condition单向链表，同时挂起线程。如果线程唤醒了，就将Condition中的Node扔到AQS的双向链表等待获取锁。

ReentrantReadWriteLock（读写锁）

发展的产物

因为ReentrantLock是互斥锁，如果有一个操作是读多写少，同时还需要保证线程安全，那么使用ReentrantLock会导致效率比较低。因为多个线程在对同一个数据进行读操作时，也不会造成线程安全问题。

所以出现了ReentrantReadWriteLock锁：读读操作是共享的，写写操作是互斥的、读写操作是互斥的、写读操作是互斥的。单个线程获取写锁后，再次获取读锁，可以拿到。（写读可重入）单个线程获取读锁后，再次获取写锁，拿不到。（读写不可重入）

ReentrantReadWriteLock还是基于AQS实现的。很多功能的实现和ReentrantLock类似还是基于AQS的state来确定当前线程是否拿到锁资源

按位来玩！之前的博客也有这部分内容哦~点击查看按位的应用【雪花算法】

state表示读锁：将state的高16位作为读锁的标识

state表示写锁：将state的低16位作为写锁的标识

锁重入：

• 写锁重入怎么玩：因为写操作和其他操作是互斥的，代表同一时间，只有一个线程持有着写锁，只要锁重入，就对低位+1即可。而且锁重入的限制，从原来的2^31 - 1，变为了2 ^ 16 -1。

• 读锁重入怎么玩：读锁的重入不能仿照写锁的方式，因为写锁属于互斥锁，同一时间只会有一个线程持有写锁，但是读锁是共享锁，同一时间会有多个线程持有读锁。所以每个获取到读锁的线程，记录锁重入的方式都是基于自己的ThreadLocal存储锁重入次数。

读锁重入的时候就不操作state了？不对，每次锁重入还要修改state，只是记录当前线程锁重入的次数，需要基于ThreadLocal记录。具体的通过源码来看

启动源码！

写锁——lock方法

public void lock() {sync.acquire(1);
}public final void acquire(int arg) {
// 尝试获取锁资源（看一下，能否以CAS的方式将state 从0 ~ 1，改成功，拿锁成功）// 成功返回// 不成功执行下面方法if (!tryAcquire(arg) &&// addWaiter：将当前没按到锁资源的，封装成Node，排到AQS里// acquireQueued：当前排队的能否竞争锁资源，不能挂起线程阻塞acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt();
}

写锁——tryAcquire方法

// 读写锁的写锁，获取流程
protected final boolean tryAcquire(int acquires) {Thread current = Thread.currentThread();int c = getState();// 拿到了写锁的低16位标识wint w = exclusiveCount(c);// c != 0：要么有读操作拿着锁，要么有写操作拿着锁if (c != 0) {// (Note: if c != 0 and w == 0 then shared count != 0)// 如果 w == 0，代表没有写锁，拿不到！走了 【有人拿着读锁】// 如果 w != 0，代表有写锁，看一下拿占用写锁是不是当前线程，如果不是，拿不到！走了【有人拿着写锁且不是自己】if (w == 0 || current != getExclusiveOwnerThread())return false;// 到这，说明肯定是写锁，并且是当前线程持有// 判断对低位 + 1，是否会超过MAX_COUNT，超过抛Errorif (w + exclusiveCount(acquires) > MAX_COUNT)throw new Error("Maximum lock count exceeded");// Reentrant acquire// 如果没超过锁重入次数， + 1，返回true，拿到锁资源。setState(c + acquires);return true;}// 到这，说明c == 0// 读写锁也分为公平锁和非公平锁// 公平：看下排队不，排队就不抢了// 走hasQueuedPredecessors方法，有排队的返回true，没排队的返回false// 非公平：直接抢！// 方法实现直接返回falseif (writerShouldBlock() ||// 以CAS的方式，将state从0修改为 1!compareAndSetState(c, c + acquires))// 要么不让抢，要么CAS操作失败，返回falsereturn false;// 将当前持有互斥锁的线程，设置为自己setExclusiveOwnerThread(current);return true;
}// state，高16：读，低16：写
00000000 00000000 00000000 0000000000000000 00000001 00000000 00000000 - SHARED_UNIT00000000 00000000 11111111 11111111 - MAX_COUNT00000000 00000000 11111111 11111111 - EXCLUSIVE_MASK
&
00000000 00000000 00000000 00000001 static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;// 只拿到表示读锁的高16位。
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
// 只拿到表示写锁的低16位。
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

剩下的addWaiter和acquireQueued和ReentrantLock看的一样，都是AQS自身提供的方法

写锁——unlock方法

读写锁的释放操作，跟ReentrantLock一致，只是需要单独获取低16位，判断是否为0，为0就释放成功

// 写锁的释放锁
public final boolean release(int arg) {// 只有tryRealse是读写锁重新实现的方法，其他的和ReentrantLock一致if (tryRelease(arg)) {Node h = head;if (h != null && h.waitStatus != 0)unparkSuccessor(h);return true;}return false;
}// 读写锁的真正释放
protected final boolean tryRelease(int releases) {// 判断释放锁的线程是不是持有锁的线程if (!isHeldExclusively())// 不是抛异常throw new IllegalMonitorStateException();// 对state - 1int nextc = getState() - releases;// 拿着next从获取低16位的值，判断是否为0boolean free = exclusiveCount(nextc) == 0;// 返回trueif (free)// 将持有互斥锁的线程信息置位nullsetExclusiveOwnerThread(null);// 将-1之后的nextc复制给statesetState(nextc);return free;
}

读锁——lock方法

public void lock() {sync.acquireShared(1);
}// 读锁加锁操作
public final void acquireShared(int arg) {// tryAcquireShared，尝试获取锁资源，获取到返回1，没获取到返回-1if (tryAcquireShared(arg) < 0)// doAcquireShared 前面没拿到锁，这边需要排队~doAcquireShared(arg);
}// tryAcquireShared方法
protected final int tryAcquireShared(int unused) {// 获取当前线程Thread current = Thread.currentThread();// 拿到stateint c = getState();// 那写锁标识，如果 !=0，代表有写锁if (exclusiveCount(c) != 0 &&// 如果持有写锁的不是当前线程，排队去！getExclusiveOwnerThread() != current)// 排队！return -1;// 没有写锁！// 获取读锁信息int r = sharedCount(c);// 公平锁： 有人排队，返回true，直接拜拜，没人排队，返回false// 非公平锁：正常的逻辑是非公平直接抢，因为是读锁，每次抢占只要CAS成功，必然成功// 这就会出现问题，写操作无法在读锁的情况抢占资源，导致写线程饥饿，一致阻塞…………// 非公平锁会查看next是否是写锁的，如果是，返回true，如果不是返回falseif (!readerShouldBlock() &&// 查看读锁是否已经达到了最大限制r < MAX_COUNT &&// 以CAS的方式，对state的高16位+1compareAndSetState(c, c + SHARED_UNIT)) {// 拿到锁资源成功！！！if (r == 0) {// 第一个拿到锁资源的线程，用first存储firstReader = current;firstReaderHoldCount = 1;} else if (firstReader == current) {// 我是锁重入，我就是第一个拿到读锁的线程，直接对firstReaderHoldCount++记录重入的次数firstReaderHoldCount++;} else {// 不是第一个拿到锁资源的// 先拿到cachedHoldCounter，最后一个线程的重入次数HoldCounter rh = cachedHoldCounter;// rh == null： 我是第二个拿到读锁的！// 或者发现之前有最后一个来的，但是不我，将我设置为最后一个。if (rh == null || rh.tid != getThreadId(current))// 获取自己的重入次数，并赋值给cachedHoldCountercachedHoldCounter = rh = readHolds.get();// 之前拿过，现在如果为0，赋值给TLelse if (rh.count == 0)readHolds.set(rh);// 重入次数+1，// 第一个：可能是第一次拿// 第二个：可能是重入操作rh.count++;}return 1;}return fullTryAcquireShared(current);
}// 通过tryAcquireShared没拿到锁资源，也没返回-1，就走这
final int fullTryAcquireShared(Thread current) {HoldCounter rh = null;for (;;) {// 拿stateint c = getState();// 现在有互斥锁，不是自己，拜拜！if (exclusiveCount(c) != 0) {if (getExclusiveOwnerThread() != current)return -1;// 公平：有排队的，进入逻辑。   没排队的，过！// 非公平：head的next是写不，是，进入逻辑。   如果不是，过！} else if (readerShouldBlock()) {// 这里代码特别乱，因为这里的代码为了处理JDK1.5的内存泄漏问题，修改过~// 这个逻辑里不会让你拿到锁，做被阻塞前的准备if (firstReader == current) {// 什么都不做} else {if (rh == null) {// 获取最后一个拿到读锁资源的rh = cachedHoldCounter;if (rh == null || rh.tid != getThreadId(current)) {// 拿到我自己的记录重入次数的。rh = readHolds.get();// 如果我的次数是0，绝对不是重入操作！if (rh.count == 0)// 将我的TL中的值移除掉，不移除会造成内存泄漏readHolds.remove();}}// 如果我的次数是0，绝对不是重入操作！if (rh.count == 0)// 返回-1，等待阻塞吧！return -1;}}// 超过读锁的最大值了没？if (sharedCount(c) == MAX_COUNT)throw new Error("Maximum lock count exceeded");// 到这，就CAS竞争锁资源if (compareAndSetState(c, c + SHARED_UNIT)) {// 跟tryAcquireShared一模一样if (sharedCount(c) == 0) {firstReader = current;firstReaderHoldCount = 1;} else if (firstReader == current) {firstReaderHoldCount++;} else {if (rh == null)rh = cachedHoldCounter;if (rh == null || rh.tid != getThreadId(current))rh = readHolds.get();else if (rh.count == 0)readHolds.set(rh);rh.count++;cachedHoldCounter = rh; }return 1;}}
}

加锁-扔到队列准备阻塞操作

// 没拿到锁，准备挂起
private void doAcquireShared(int arg) {// 将当前线程封装为Node，当前Node为共享锁，并添加到队列的模式final Node node = addWaiter(Node.SHARED);boolean failed = true;try {boolean interrupted = false;for (;;) {// 获取上一个节点final Node p = node.predecessor();if (p == head) {// 如果我的上一个是head，尝试再次获取锁资源int r = tryAcquireShared(arg);if (r >= 0) {// 如果r大于等于0，代表获取锁资源成功// 唤醒AQS中我后面的要获取读锁的线程（SHARED模式的Node）setHeadAndPropagate(node, r);p.next = null; if (interrupted)selfInterrupt();failed = false;return;}}// 能否挂起当前线程，需要保证我前面Node的状态为-1，才能执行后面操作if (shouldParkAfterFailedAcquire(p, node) &&//LockSupport.park挂起~~parkAndCheckInterrupt())interrupted = true;}} finally {if (failed)cancelAcquire(node);}
}