抽象同步器AQS、CAS应用之--ReentrantLock，lock和unlock的流程、源码分析

文章目录

1. AQS和CAS
- 1.1 CAS存在的bug：ABA问题
2. ReentrantLock和synchronized的区别
3. ReentrantLock的内部结构
- 3.1 lock、tryLock 的区别
4. ReentrantLock.lock的工作流程，源码分析
- 4.1 LockSupport.park阻塞原理
- 4.2 interrupt、interrupted 、isInterrupted 的区别
5. ReentrantLock.unlock的工作流程，源码分析
6. 手写AQS，实现自定义锁
6. 死锁面试题：如何预防程序死锁？

多线程重点：各种锁的区别！

1. AQS和CAS

多线程中经常听到AQS和CAS，他们究竟是什么呢？

1.1 AQS:
AbstractQueuedSynchronizer（AQS）抽象队列同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch等。在实现AQS时，一般通过定义内部类Sync继承AQS，将同步器所有调用都映射到Sync对应的方法来处理。

AQS定义两种资源共享方式：

①：独占：只有一个线程能执行，如ReentrantLock
```
static final Node EXCLUSIVE = null;
```
②：共享：多个线程可以同时执行，如Semaphore/CountDownLatch
```
static final Node SHARED = new Node();
```

AQS定义两种队列：

①：同步等待队列 ：AQS当中的同步等待队列也称CLH队列，CLH队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列，是FIFO先入先出线程等待队列
```
        Node(Thread thread, Node mode) {     // Used by addWaiterthis.nextWaiter = mode;this.thread = thread;}
```

同步等待队列的进入时机：

当前线程获取锁失败后，同步器会将线程构建成一个节点，并将其加入同步队列中。
通过signal或signalAll将条件队列中的节点转移到同步队列。（由条件队列转化为同步队列）
②：条件等待队列：Condition是一个多线程间协调通信的工具类，使得某个，或者某些线程一起等待某个条件（Condition）,只有当该条件具备时，这些等待线程才会被唤醒，从而重新争夺锁
```
        Node(Thread thread, int waitStatus) { // Used by Conditionthis.waitStatus = waitStatus;this.thread = thread;}
```

条件等待队列的进入时机：

调用await方法阻塞线程；

注意：一个线程只能存在于两个队列中的一个

AQS四大核心原理

队列元素自旋获取锁：阻塞的线程通过自旋不断尝试加锁，加锁成功则跳出循环
LockSupport：通过LockSupport.park()和LockSupport.unpark()
CAS：无锁算法，功能类似于Synchronized
队列：保存每个阻塞线程的引用

=========================================================

1.2 CAS

compare and swap（CAS），比较与交换。作用：不管并发有多高，都能保证操作的原子性，保证锁的互斥性。CAS是保证并发安全性的一条CPU底层原子指令cmpxchg（x86框架下），它的功能是判断某个值是否为预期值，如果是的话，就改为新值，在CAS过程中不会被中断。

但CPU底层原子指令cmpxchg仅仅能保证原子性，如果java中的CAS只有这项功能肯定是不行的！因为并发安全需要原子性、一致性、可见性都得到保证，java中的compareAndSwapXxx方法其实在jvm底层又增加了Lock前缀去保证其他并发安全特性的！所以在java中可以使用CAS达到Sychronized、Lock同样的功能

然而在Java发展初期，并不能直接利用硬件提供的并发来提升系统的性能的，随着java的发展，CAS理论成为实现java并发的一种常用手段。

CAS包含三个参数：

①：偏移量：要更新的变量（V）在内存中的偏移量
②：预期值（A）
③：新值（B）

什么是偏移量：从堆内存中对象头的Mark Word(起始位置)开始数，直到存储该成员变量V的起始值，这个起始值被称为当前对象的成员变量V的偏移量，也就是内存中记录V的位置，用于cpu寻址，进而进行cas中的比较！！

如果内存位置的值与预期值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值

对于某个对象中的变量V，如果想要通过CAS无锁且安全的方式修改这个变量V的值，具体的逻辑如下：

通过cpu寻址找到该变量V在对象中的偏移量，拿到V的原始值。
拿V的原始值和预期值（A）作比较
如果当前值和预期值一样，则修改V的值为新值（B）
如果当前值和预期值不一样，则不能修改V的原始值，可以选择自旋，重新获取V的值，直到V的值等于预期值（A）才可以对V进行修改！

如以上逻辑，通过CAS操作，保证整个操作过程是原子的，任意时刻只有一个线程执行成功！

cas的实现：

主要是使用的Unsafe类的这三个native方法，再底层就是调用的汇编的原子指令cmpxchg()，依赖于硬件完成！

/**
* Object var1：对象
* long var2：对象中某变量的偏移量
* int var4：期望值
* int var5：想要修改的值
*/
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

1.1 CAS存在的bug：ABA问题

因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，然后又变成了A，那么此时使用CAS进行检查时会发现它的值没有发生变化，依旧是A，最终结果没有变。但是实际上，A却经历了A-B-A的过程，这就是CAS存在的ABA问题！

ABA问题示例

//要修改的变量
private static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);public static void main(String[] args) {//线程一 修改后又恢复原样new Thread(() -> {atomicReference.compareAndSet(100, 101);atomicReference.compareAndSet(101, 100);},"t1").start();//线程二：还可以修改，无法解决ABA问题new Thread(() -> {try {//睡一秒，让线程一先修改TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}System.out.println(atomicReference.compareAndSet(100, 2019) + "\t修改后的值:" + atomicReference.get());},"t2").start();
}

初始值为100，线程t1将100改成101，然后又将101改回100

线程t2先睡眠1秒，等待t1操作完成，然后t2线程将值改成2019

可以看到，线程2修改成功

输出结果：true 修改后的值:2019

ABA问题的危害

一般场景下，使用CAS处理一些数值的简单计算，ABA并不会出现什么问题，但是当涉及到引用的时候就会出问题。

比如：使用CAS导致栈结构变化

现有一个用单向链表实现的堆栈，栈顶为A，这时线程T1已经知道A.next为B
然后希望用CAS将栈顶替换为B，使栈中元素为B、B：head.compareAndSet(A,B)
在T1执行上面这条指令之前，由于T1还没有进入CAS，存在线程争抢！此时线程T2介入，将A、B出栈，再pushD、C、A，此时堆栈结构如下图，而对象B此时处于游离状态：
此时轮到线程T1执行CAS操作，检测发现栈顶仍为A，所以CAS成功，栈顶变为B，但实际上B.next为null，所以此时的情况变为：
最后堆栈中只有B一个元素，C和D组成的链表不再存在于堆栈中，平白无故就把C、D丢掉了。

ABA解决方案：

使用版本号。在变量前面追加版本号，每次变量更新的时候把版本号+1，那么A->B->A 就会变成1A->2B->3A，在进行CAS比较时，即使值相同，也不应该修改成功，还要比对版本号！从JDK1.5 开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。AtomicStampedReference除了定义值，还可以定义版本号

// AtomicStampedReference定义值为100 ，版本号为1
private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<Integer>(100,1);public static void main(String[] args) {//线程一new Thread(() -> {System.out.println("t1拿到的初始版本号:" + atomicStampedReference.getStamp());//睡眠1秒，是为了让t2线程也拿到同样的初始版本号TimeUnit.SECONDS.sleep(1);//干坏事，修改原始值    atomicStampedReference.compareAndSet(100, 101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);atomicStampedReference.compareAndSet(101, 100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);},"t1").start();//线程二new Thread(() -> {int stamp = atomicStampedReference.getStamp();System.out.println("t2拿到的初始版本号:" + stamp);//睡眠3秒，是为了让t1线程完成ABA操作TimeUnit.SECONDS.sleep(3);System.out.println("最新版本号:" + atomicStampedReference.getStamp());System.out.println(atomicStampedReference.compareAndSet(100, 2019,stamp,atomicStampedReference.getStamp() + 1) + "\t当前 值:" + atomicStampedReference.getReference());},"t2").start();
}

初始值100，初始版本号1

线程t1和t2拿到一样的初始版本号1

线程t1完成ABA操作，版本号递增到3

线程t2完成CAS操作，最新版本号已经变成3，跟线程t2之前拿到的版本号1不相等，操作失败

输出结果：
t1拿到的初始版本号:1
t2拿到的初始版本号:1
最新版本号:3
false 当前值:100

从上述代码我们知道了AtomicStampedReference可以给引用加上版本号，追踪引用的整个变化过程，如：A -> B -> C -> D - > A，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了3次

但是，有时候，我们并不关心引用变量更改了几次，只是单纯的关心是否更改过，所以就有了AtomicMarkableReference，它与AtomicStampedReference唯一的区别就是不再用int标识引用，而是使用boolean变量——表示引用变量是否被更改过！

CAS的其他缺陷

CAS自旋如果长时间不成功，会给CPU带来很大开销！
无法同时对多个共享变量使用CAS，当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性。这个时候就可以用synchronized锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。
从Java 1.5开始，JDK提供了AtomicReference类来保证引用对之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

2. ReentrantLock和synchronized的区别

ReentrantLock是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于synchronized是一种互斥锁，可以保证线程安全。而且它具有比 synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。

相同点：
①：都是可重入锁；锁可以被一个线程反复加多次。比如：加锁的方法递归调用。在一个方法内执行多次lock.lock()，重入的次数记录在state状态量上，状态量随着重入此时不断递增。

②：都是阻塞式同步；也就是说当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待

不同点：

	SynChronized	ReentrantLock
1.底层实现	java语言的关键字,需要jvm实现	是JDK 1.6之后提供的API层面的互斥锁类
2.便利性	由编译器保证锁的加锁和释放，简洁方便	需要手动加锁和释放锁，最好在finally中声明释放锁。
3.灵活性	锁的是方法或者代码块	lock() 方法是调用的，可以跨方法，灵活性更高
4.等待可中断	不可中断，除非抛出异常 (释放锁方式1.代码执行完，正常释放锁； 2.抛出异常，由JVM退出等待)	持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待, (方法： 1.设置超时方法 tryLock(long timeout, TimeUnit unit)，时间过了就放弃等待； 2.lockInterruptibly()放代码块中，调用interrupt()方法可中断，而synchronized不行)
5.是否公平锁	非公平锁	两者都可以，默认公平锁，构造器可以传入boolean值，true为公平锁，false为非公平锁
6.条件Condition		ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程
5.锁信息监听		提供很多方法用来监听当前锁的信息，如： getHoldCount() getQueueLength() isFair() isHeldByCurrentThread() isLocked()

2. 线程通信的区别

Java 线程通信最常用的就是经典的三种:

volatile ：加在共享变量上，可以保证变量在不同线程之间的可见性和有序性，不同线程通过该变量的值，做具体逻辑处理！
synchronized 下使用object的wait，notify方法对：生产者和消费者模型通过wait，notify实现等待和唤醒，在我的上一篇文章中有详细解释，点击此处查看！
ReentrantLock下使用condition的await，signal方法对

下面来看一下ReentrantLock中condition类的await，signal方法对，是如何做线程通信的！

public class ConditionBuffer implements Buffer{//创建ReentrantLockprivate Lock lock = new ReentrantLock();//使用ReentrantLock创建两个Conditionprivate Condition notEmpty = lock.newCondition();private Condition notFull = lock.newCondition();private final static int CAPACITY = 1;private int count = 0;private ArrayList<Integer> list = new ArrayList<>(CAPACITY);public ArrayList<Integer> getList(){return list;}//向集合中添加元素public void put(Integer e) throws InterruptedException{if(e == null){return;}lock.lock();try{//判断while(count == CAPACITY){//如果count == 1 触发等待notFull.await();System.out.println("Reentrant_put: "+Thread.currentThread());}list.add(e);count++;//唤醒其他线程，把count变为0notEmpty.signal();}finally {lock.unlock();}}//从集合中取元素public Integer take() throws InterruptedException{lock.lock();//判断while(count == 0){//如果count == 0 触发等待notEmpty.await();System.out.println("Reentrant_take: "+Thread.currentThread());}try{Integer e = list.get(count % CAPACITY);count --;//唤醒其他线程，把count变为1notFull.signal();return e;}finally {lock.unlock();}}
}

可以看到代码与synchronized的通信类似，只不过是用condition的await和signal代替object的wait，notify来做线程通信！

那么 Condition 比 object 通信好在哪？？

object如果是以notifyAll来唤醒的，所以所有等待中的线程，无论是生产者和消费者都要被唤醒。然后生产者唤醒后经过判断后还是会进入wait，等于说醒来后什么都没干，造成线程切换的资源浪费
Condition可以实现精准唤醒。也就是说生产者唤醒的永远是消费者, 反之亦然。可有效减少资源消耗！

3. ReentrantLock的内部结构

** ReentrantLock整体结构**

通过代码可以看到Sync继承了AQS
ReentrantLock内部又通过继承Sync抽象类的方式实现了公平锁和非公平锁

    //公平锁static final class FairSync extends Sync //非公平锁static final class NonfairSync extends Sync

公平锁和非公平锁的区别是什么？

当上一个线程释放锁后，新来的线程开始抢锁。

公平锁：如果队列中有等待的线程，不跟队列中的线程抢锁，默默的排到队列中，等待唤醒。
非公平锁：不管队列中有没有线程，上去就抢，抢不到再进入队列

AQS在内部维护了一个队列，这个队列就是一个双向链表，用来存储那些获取锁失败，入队阻塞，等待唤醒的线程。

AQS内部有几个核心的成员变量

state ：状态量，代表着锁是否被占有。 1-锁被占有 0-锁空闲,可获取，线程获取锁后通过CAS设置state的状态！
head ：队列的头节点Node，只有一个
tail：队列的尾节点Node，只有一个

还有一个重要的内部类Node，他里边封装着每一个线程的信息

 static final class Node {//等待状态 ，volatile保证线程可见性， 即被一个线程修改后，状态会立马让其他线程可见-1 ： 可被唤醒1 ： 失效-2 ： 调度-3 ： 传播 volatile int waitStatus;//当前节点的前一个节点volatile Node prev;//当前节点的后一个节点volatile Node next;//标记该节点属于哪个线程的volatile Thread thread;}

清楚了，AQS和ReentrantLock的大体结构，下面看ReentrantLock.lock()是如果加锁的！！

3.1 lock、tryLock 的区别

ReentrantLock的常用API

 public void lock() {sync.lock();}public void lockInterruptibly() throws InterruptedException {sync.acquireInterruptibly(1);}public boolean tryLock() {return sync.nonfairTryAcquire(1);}public boolean tryLock(long timeout, TimeUnit unit)throws InterruptedException {return sync.tryAcquireNanos(1, unit.toNanos(timeout));}

用一个例子来说明上述API的使用

假如线程A和线程B使用同一个锁LOCK，此时线程A首先获取到锁LOCK.lock()，并且始终持有不释放。如果此时B要去获取锁，有四种方式：

LOCK.lock(): 此方式会始终处于等待中，即使调用B.interrupt()也不能中断，除非线程A调用LOCK.unlock()释放锁。
LOCK.lockInterruptibly(): 此方式会等待，但当调用B.interrupt()会被中断等待，并抛出InterruptedException异常，否则会与lock()一样始终处于等待中，直到线程A释放锁。
LOCK.tryLock(): 该处不会等待，获取不到锁并直接返回false，去执行下面的逻辑。
LOCK.tryLock(10, TimeUnit.SECONDS)：该处会在10秒时间内处于等待中，但当调用B.interrupt()会被中断等待，并抛出InterruptedException。10秒时间内如果线程A释放锁，会获取到锁并返回true，否则10秒过后会获取不到锁并返回false，去执行下面的逻辑。

所以 lock、tryLock API 的区别如下：

lock拿不到锁会一直等待，tryLock是去尝试，拿不到就返回false，拿到返回true。
lock是不可以被中断的，tryLock可以被中断！

4. ReentrantLock.lock的工作流程，源码分析

以公平锁为例：
当我们调用 ReentrantLock.lock时，会进入AQS的acquire() 方法

     //公平锁FairSync 中的lock方法 ，传入的state状态量是1final void lock() {acquire(1);}

 //AQS中的加锁逻辑，接收state状态量1public final void acquire(int arg) {if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt();}

AQS的这几个方法就是加锁的核心，下面一个个来看这些方法。

tryAcquire(arg)尝试获取锁：

 protected final boolean tryAcquire(int acquires) {//获取当前线程currentfinal Thread current = Thread.currentThread();//获取状态量int c = getState();if (c == 0) {//如果状态量=0，代表锁空闲。同时检查队列是否有线程等待if (!hasQueuedPredecessors() &&//如果队列中没有线程，就用CAS设置状态量为1，代表我独占锁compareAndSetState(0, acquires)) {//如果队列中没有线程，就独占锁，执行业务代码setExclusiveOwnerThread(current);return true;}}//如果状态量！=0，且独占锁的是当前线程，发生了重入//意思就是：可重入特性，锁被一个线程反复加了多次（递归）else if (current == getExclusiveOwnerThread()) {//发生可重入就把状态量+1，执行业务代码int nextc = c + acquires;if (nextc < 0)throw new Error("Maximum lock count exceeded");//这里不使用CAS的原因：在这个else if中属于当前线程独占，//锁独占模式别的线程进不来setState(nextc);return true;}//如果状态量！=0，且不是本线程重入，入队、阻塞！return false;}

addWaiter(Node.EXCLUSIVE) 线程入队：

    private Node addWaiter(Node mode) {//为当前线程创建一个节点nodeNode node = new Node(Thread.currentThread(), mode);//队列的尾节点tail为null，赋值给predNode pred = tail;if (pred != null) {node.prev = pred;if (compareAndSetTail(pred, node)) {pred.next = node;return node;}}//由于pred为null，不走上面的if，进入enq方法enq(node);return node;}//enq方法代码如下：private Node enq(final Node node) {//死循环for (;;) {//tail等于null，t等于nullNode t = tail;//判断队列是否初始化if (t == null) { //第一次循环，tail为null，为tail创建一个节点互斥Node，完成初始化if (compareAndSetHead(new Node()))//因为此时还没有线程节点，所以此时的head==tail，只有一个tail = head;} else {//第二次循环，把当前线程节点放入head节点后边//并通过 prev、next 创建链表的关联！node.prev = t;//为什么这里用CAS保证入队的安全？保证入队的安全//因为在入队时cpu可能会被别的线程抢占，如果被抢，next指向其他线程，那么当前线程不在队列中存在，将永远无法被唤醒！if (compareAndSetTail(t, node)) {t.next = node;return t;}}}}

至此，线程入队完成，但还需要阻塞
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)：阻塞入队线程

   final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;//死循环for (;;) {//获取当前线程节点的上一个节点 pfinal Node p = node.predecessor();//当前线程是head后紧跟的第一个节点，不直接阻塞，先让他尝试获取一次锁if (p == head && tryAcquire(arg)) {//如果获取成功，把当前线程节点设置为head节点setHead(node);//原来的head节点被GC处理掉！p.next = null; // help GCfailed = false;return interrupted;}//如果获取不成功，再阻塞//注意：阻塞时，要把等待状态waitstatus修改为-1，代表这个线程可被唤醒！if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())interrupted = true;}} finally {if (failed)cancelAcquire(node);}}
==========================================================注意：阻塞时，要把等待状态waitstatus修改为-1，代表这个线程可被唤醒！方法是shouldParkAfterFailedAcquire(p, node)
shouldParkAfterFailedAcquire(p, node) 方法如下：private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {//获取上一个节点的waitStatusint ws = pred.waitStatus;//如果waitStatus = -1，代表可被唤醒，返回true可以进行阻塞了if (ws == Node.SIGNAL)return true;//如果waitStatus > 0，代表线程已失效if (ws > 0) {do {node.prev = pred = pred.prev;} while (pred.waitStatus > 0);pred.next = node;} else {//其他情况把waitStatus 通过CAS设置为-1，返回false，在下一次循环中阻塞，原因下面会讲！compareAndSetWaitStatus(pred, ws, Node.SIGNAL);}return false;}==========================================================//阻塞的方法parkAndCheckInterrupt（）如下private final boolean parkAndCheckInterrupt() {//调用LockSupport.park方法进行阻塞LockSupport.park(this);return Thread.interrupted();}

4.1 LockSupport.park阻塞原理

从上述代码中，我们知道线程入队阻塞是通过LockSupport.park(this)这段代码来完成的，那么这段代码有什么含义呢？LockSupport可以理解为一个工具类。它的作用很简单，就是挂起和继续执行线程。它的常用的API如下：

public static void park() : 如果没有可用许可，则挂起当前线程
public static void unpark(Thread thread)：给thread一个可用的许可，让它得以继续执行

需要注意的是：LockSupport的park和unpark都是基于许可的实现

首先看一下park的源码：可以看到是调用native本地方法来执行的！unpark亦是如此！

public native void park(boolean var1, long var2);

如何理解LockSupport是基于许可的实现呢？请看下面代码：

    public static void main(String[] args) {LockSupport.unpark(Thread.currentThread());System.out.println("调用unpark方法给当前线程添加许可！");System.out.println("调用park方法阻塞线程！");LockSupport.park();System.out.println("执行业务逻辑。。。");}

不妨猜一下：park()之后，当前线程是停止，还是可以继续执行呢？

答案是：可以继续执行。那是因为在park()之前，先执行了unpark()，进而给当前线程释放了一个许可，也就是说当前线程有一个可用的许可。而park()在有可用许可的情况下，是不会阻塞线程的。

打印结果如下：

综上所述，park()和unpark()的执行效果和它调用的先后顺序没有关系。这一点相当重要，因为在一个多线程的环境中，我们往往很难保证函数调用的先后顺序(都在不同的线程中并发执行)，因此，这种基于许可的做法能够最大限度保证程序不出错。在AbstractQueuedSynchronizer中，也正是使用了LockSupport的park()和unpark()操作，来控制线程的运行状态的。

案例：使用LockSupport的park和unpark完成两个数组交替打印

public class park {static Thread t1 = null;static Thread t2 = null;public static void main(String[] args) {char[] nums = "1234567".toCharArray();char[] chars = "ABCDEFG".toCharArray();t1 = new Thread(() -> {for (char c : nums) {//线程1先打印System.out.print(c + " ");//线程一park前先唤醒线程二LockSupport.unpark(t2);LockSupport.park();}}, "t1");t2 = new Thread(() -> {for (char c : chars) {//为保证线程一先打印，线程二进来就park住LockSupport.park();//线程二被唤醒后打印System.out.print(c + " ");//线程二打印完唤醒线程一LockSupport.unpark(t1);}}, "t2");t1.start();t2.start();}
}

打印结果：

4.2 interrupt、interrupted 、isInterrupted 的区别

首先三者都属于Thread类中的方法

interrupt 方法

    public void interrupt() {if (this != Thread.currentThread())checkAccess();synchronized (blockerLock) {Interruptible b = blocker;if (b != null) {// 调用的native方法为线程设置一个中断标记interrupt0();           // Just to set the interrupt flagb.interrupt(this);return;}}interrupt0();}

interrupt方法仅仅是置线程的中断状态位为中断状态，不会立马停止线程。需要用户自己去监视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出interruptedException的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。

所以调用interrupt()时：

如果线程处于阻塞状态，如sleep、wait等状态，此时监控到中断标志设置为true，那么线程将立即退出阻塞状态，并抛出一个InterruptedException异常
如果线程处于正常活动状态，那么只会将该线程的中断标志设置为true，被设置中断标志的线程将继续正常运行，不受影响。

interrupted 方法

    public static boolean interrupted() {//注意：其内部调用的是：isInterrupted方法，不过入参为truereturn currentThread().isInterrupted(true);}

isInterrupted 方法

    public boolean isInterrupted() {return isInterrupted(false);}

可以看到，interrupted() 、isInterrupted()其底层都是调用的isInterrupted方法，只不过入参不同。isInterrupted方法作为一个native方法，源码如下

    /*** Tests if some Thread has been interrupted.  The interrupted state* is reset or not based on the value of ClearInterrupted that is* passed.* 测试线程是否被中断，入参ClearInterrupted的值 可以重置中断状态* 为true：清除中断状态* 为false：不清除中断状态*/private native boolean isInterrupted(boolean ClearInterrupted);

所以interrupt()、interrupted() 、isInterrupted()的区别就在于

interrupt()
- 只是为当前线程添加一个中断标识，不会立马中断正在运行的线程，而是在安全位置（sleep，wait）监视线程状态，如果监控到线程被 interrupt()标记为中断，则会立马抛出InterruptedException异常
- interrupt()属于比较正确的线程中断方式，另外一些方法stop()、suspend() 和 resume()等方法中断线程时太过暴力，调用后会直接释放锁，可能会导致数据不同步的问题！
interrupted()
- 获取当前线程的中断状态，同时清除interrupt()标记的中断标识。
- 如果先执行interrupt()，打上中断标识，然后执行interrupted()方法，第一次执行结果为true，第二次执行结果为false，因为第一次执行时清除了中断标识
isInterrupted()
- 仅获取当前线程的中断状态，不清除中断标识。
- 如果先执行interrupt()，打上中断标识，然后执行isInterrupted()方法，第一次执行结果为true，第二次执行结果仍为true，因为isInterrupted()并没有清除中断标识！

5. ReentrantLock.unlock的工作流程，源码分析

在调用ReentrantLock.unlock()方法时，会进行解锁

//ReentrantLock的unlock，release传入1public void unlock() {//把当前的状态量state=1传入sync.release(1);}

 //AQS的release()方法，接收传进来的状态量state = 1public final boolean release(int arg) {//tryRelease（）释放锁的先决条件if (tryRelease(arg)) {Node h = head;//只有head节点不为空且waitStatus ！=0时才可能释放锁//这也是阻塞方法shouldParkAfterFailedAcquire()要把waitStatus设置为-1的原因if (h != null && h.waitStatus != 0)//释放锁的方法unparkSuccessor(h);return true;}return false;}==========================================================//tryRelease（）释放锁的先决条件，代码如下protected final boolean tryRelease(int releases) {//c是waitstatus  c = 1-1 =0 int c = getState() - releases;//如果线程不匹配，抛异常if (Thread.currentThread() != getExclusiveOwnerThread())throw new IllegalMonitorStateException();boolean free = false;if (c == 0) {free = true;//撤销绑定的线程setExclusiveOwnerThread(null);}//设置waitstatus 为0，表示锁空闲，可争抢！setState(c);return free;}==========================================================释放锁的方法unparkSuccessor(h)代码如下private void unparkSuccessor(Node node) {//获取head节点的waitStatus = -1int ws = node.waitStatus;if (ws < 0)//在这里把waitStatus = -1 置为初始状态0compareAndSetWaitStatus(node, ws, 0);//获取head节点的下一个节点，也就是当前线程Node s = node.next;if (s == null || s.waitStatus > 0) {s = null;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);}

问题：head节点的waitStatus为什么要在阻塞的时候由0 => -1，为什么要在释放锁的时候由-1 => 0 ？

0 => -1 : 因为持有锁的线程T0在释放锁时，要判断head节点的waitStatus是否!=0，如果等于0则不会执行释放锁逻辑，所以要把head节点的waitStatus由0改为-1。

-1 => 0 ：释放锁后把waitStatus置为初始状态0。释放锁后唤醒了队列中的第一个阻塞线程，在非公平锁状态下，这个线程会再次for循环尝试获取锁，如果没获取到，依旧会阻塞。阻塞方法shouldParkAfterFailedAcquire()要把waitStatus设置为-1，并返回false，然后再次循环获取锁。

如果不把waitStatus状态变为0的话，shouldParkAfterFailedAcquire()会直接返回true，不会再次循环尝试获取锁。那么这个线程就永远阻塞了！

6. 手写AQS，实现自定义锁

Mylock替代ReentrantLock:

public class MyLock {private final Sync sync;public MyLock() {this.sync = new Sync();}public void lock() {sync.lock();}public void unlock() {sync.release();}//sync是AQS的简化版static final class Sync {// 记录持有锁的线程private Thread current;private static final Unsafe unsafe = getUnsafe();// 偏移量private static long offset;// 记录当前状态private volatile int state = 0;//生成偏移量，用来cas算法计算！static {try {offset = unsafe.objectFieldOffset(Sync.class.getDeclaredField("state"));} catch (NoSuchFieldException e) {e.printStackTrace();}}//获取Unsafe类private static Unsafe getUnsafe() {Field f = null;try {f = Unsafe.class.getDeclaredField("theUnsafe");f.setAccessible(true);return (Unsafe) f.get(null);} catch (NoSuchFieldException | IllegalAccessException e) {e.printStackTrace();}return null;}// CAS算法获取锁private boolean compareAndSetState(int oldValue, int expectValue) {return unsafe.compareAndSwapInt(this, offset, oldValue, expectValue);}public void lock() {// 获取锁失败的线程自旋等待锁while (!tryLock()) {try {// 等待500毫秒观察效果Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}}}//非公平锁public boolean tryLock() {// 如果state=0，尝试获取锁if (state == 0) {if (compareAndSetState(0, 1)) {// 获取到锁,修改状态=1，记录当前线程到成员变量this.state = 1;this.current = Thread.currentThread();System.out.println(current.getName() + "==============》》获取锁");return true;}} else {// 如果是可重入锁，+1if (this.current == Thread.currentThread()) {this.state++;System.out.println(current.getName() + "==============》》重入");return true;}}// 滚去睡觉System.err.println(Thread.currentThread().getName() + "==========》》获取锁失败");return false;}public void release() {System.out.println(current.getName() + "《《=============释放锁");this.current = null;state--;}}
}

main方法测试：

public class MyLockTest {public static void main(String[] args) {MyLock myLock = new MyLock();Runnable runnable = () -> {myLock.lock();System.out.println(Thread.currentThread().getName() + "正在处理。。。。");myLock.unlock();};for (int i = 1; i <=50; i++) {new Thread(runnable,"线程"+i).start();}}
}

测试结果：

完成了锁互斥性的实现

6. 死锁面试题：如何预防程序死锁？

死锁是什么，产生死锁的条件，如何预防与解除死锁？