目录
tips：如果竞争比较激烈，推荐lock锁，效率更高；如果几乎没有竞争，推荐synchronized
延伸问题：AQS是什么？【AbstractQueuedSynchronizer】
硬件内存结构&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());
else
acquire(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的state
int c = getState();
// 如果state == 0，说明没有线程占用着当前的锁资源
if (c == 0) {
// 判断是否有线程在排队，如果有线程排队，返回true，配上前面的!，那会直接不执行返回最外层的false
if (!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");
// 将值设置给state
setState(nextc);
// 拿锁成功
return true;
}
return false;
}非公平锁：
// 非公平锁实现
final boolean nonfairTryAcquire(int acquires) {
// 拿到当前线程！
final Thread current = Thread.currentThread();
// 拿到AQS的state
int c = getState();
// 如果state == 0，说明没有线程占用着当前的锁资源
if (c == 0) {
// 没人占用锁资源，直接抢一波（不管有没有线程在排队）
if (compareAndSetState(0, acquires)) {
// 将当前占用这个互斥锁的线程属性设置为当前线程
setExclusiveOwnerThread(current);
// 返回true，拿锁成功
return true;
}
}
// 当前state != 0，说明有线程占用着锁资源
// 判断拿着锁的线程是不是当前线程（锁重入）
else if (current == getExclusiveOwnerThread()) {
// 将state再次+1
int nextc = c + acquires;
// 锁重入是否超过最大限制
// 01111111 11111111 11111111 11111111 + 1
// 10000000 00000000 00000000 00000000
// 抛出error
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
// 将值设置给state
setState(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 (;;) {
// 拿到tail
Node t = tail;
// 如果tail为null，说明当前没有Node在队列中
if (t == null) {
// 创建一个新的Node作为head，并且将tail和head指向一个Node
if (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的next
tryAcquire(arg)) { // 竞争锁资源，成功：true，失败：false
// 进来说明拿到锁资源成功
// 将当前节点置位head，thread和prev属性置位null
setHead(node);
// 帮助快速GC
p.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;
// 如果上一个节点为 -1
if (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的节点状态该为-1
compareAndSetWaitStatus(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 != 0
return false;
}
// 核心的释放锁资源方法
protected final boolean tryRelease(int releases) {
// 获取state - 1
int c = getState() - releases;
// 如果释放锁的线程不是占用锁的线程，抛异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// 是否成功的将锁资源释放利索 （state == 0）
boolean free = false;
if (c == 0) {
// 锁资源释放干净。
free = true;
// 将占用锁资源的属性设置为null
setExclusiveOwnerThread(null);
}
// 将state赋值
setState(c);
// 返回true，代表释放干净了
return free;
}
// 唤醒节点
private void unparkSuccessor(Node node) {
// 拿到头节点状态
int ws = node.waitStatus;
// 如果头节点状态小于0，换为0
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
// 拿到当前节点的next
Node s = node.next;
// 如果s == null ，或者s的状态为1
if (s == null || s.waitStatus > 0) {
// next节点不需要唤醒，需要唤醒next的next
s = null;
// 从尾部往前找，找到状态正常的节点。（小于等于0代表正常状态）
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
// 经过循环的获取，如果拿到状态正常的节点，并且不为null
if (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位标识w
int 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，超过抛Error
if (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
// 非公平：直接抢！
// 方法实现直接返回false
if (writerShouldBlock() ||
// 以CAS的方式，将state从0修改为 1
!compareAndSetState(c, c + acquires))
// 要么不让抢，要么CAS操作失败，返回false
return false;
// 将当前持有互斥锁的线程，设置为自己
setExclusiveOwnerThread(current);
return true;
}
// state，高16：读，低16：写
00000000 00000000 00000000 00000000
00000000 00000001 00000000 00000000 - SHARED_UNIT
00000000 00000000 11111111 11111111 - MAX_COUNT
00000000 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 - 1
int nextc = getState() - releases;
// 拿着next从获取低16位的值，判断是否为0
boolean free = exclusiveCount(nextc) == 0;
// 返回true
if (free)
// 将持有互斥锁的线程信息置位null
setExclusiveOwnerThread(null);
// 将-1之后的nextc复制给state
setState(nextc);
return free;
}读锁——lock方法
public void lock() {
sync.acquireShared(1);
}
// 读锁加锁操作
public final void acquireShared(int arg) {
// tryAcquireShared，尝试获取锁资源，获取到返回1，没获取到返回-1
if (tryAcquireShared(arg) < 0)
// doAcquireShared 前面没拿到锁，这边需要排队~
doAcquireShared(arg);
}
// tryAcquireShared方法
protected final int tryAcquireShared(int unused) {
// 获取当前线程
Thread current = Thread.currentThread();
// 拿到state
int c = getState();
// 那写锁标识，如果 !=0，代表有写锁
if (exclusiveCount(c) != 0 &&
// 如果持有写锁的不是当前线程，排队去！
getExclusiveOwnerThread() != current)
// 排队！
return -1;
// 没有写锁！
// 获取读锁信息
int r = sharedCount(c);
// 公平锁： 有人排队，返回true，直接拜拜，没人排队，返回false
// 非公平锁：正常的逻辑是非公平直接抢，因为是读锁，每次抢占只要CAS成功，必然成功
// 这就会出现问题，写操作无法在读锁的情况抢占资源，导致写线程饥饿，一致阻塞…………
// 非公平锁会查看next是否是写锁的，如果是，返回true，如果不是返回false
if (!readerShouldBlock() &&
// 查看读锁是否已经达到了最大限制
r < MAX_COUNT &&
// 以CAS的方式，对state的高16位+1
compareAndSetState(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))
// 获取自己的重入次数，并赋值给cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 之前拿过，现在如果为0，赋值给TL
else 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 (;;) {
// 拿state
int 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);
}
}