文章目录
1. AQS和CAS
多线程中经常听到AQS和CAS，他们究竟是什么呢？
1.1 AQS:
AbstractQueuedSynchronizer（AQS）抽象队列同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch等。在实现AQS时，一般通过定义内部类Sync继承AQS，将同步器所有调用都映射到Sync对应的方法来处理。
AQS定义两种资源共享方式：
-
①：独占：只有一个线程能执行，如
ReentrantLockstatic final Node EXCLUSIVE = null; -
②：共享：多个线程可以同时执行，如
Semaphore/CountDownLatchstatic final Node SHARED = new Node();
AQS定义两种队列：
-
①：同步等待队列 ：
AQS当中的同步等待队列也称CLH队列，CLH队列是Craig、Landin、Hagersten三人 发明的一种基于双向链表数据结构的队列，是FIFO先入先出线程等待队列Node(Thread thread, Node mode) { // Used by addWaiter this.nextWaiter = mode; this.thread = thread; }
同步等待队列的进入时机：
-
当前线程获取锁失败后，同步器会将线程构建成一个节点，并将其加入同步队列中。
-
通过
signal或signalAll将条件队列中的节点转移到同步队列。（由条件队列转化为同步队列）
-
②：条件等待队列：
Condition是一个多线程间协调通信的工具类，使得某个，或者某些线程一起等待某个条件（Condition）,只有当该条件具备时，这些等待线程才会被唤醒，从而重新争夺锁Node(Thread thread, int waitStatus) { // Used by Condition this.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{
//创建ReentrantLock
private Lock lock = new ReentrantLock();
//使用ReentrantLock创建两个Condition
private 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变为0
notEmpty.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变为1
notFull.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状态量是1
final void lock() {
acquire(1);
}
//AQS中的加锁逻辑，接收state状态量1
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
AQS的这几个方法就是加锁的核心，下面一个个来看这些方法。
tryAcquire(arg)尝试获取锁：
protected final boolean tryAcquire(int acquires) {
//获取当前线程current
final 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) {
//为当前线程创建一个节点node
Node node = new Node(Thread.currentThread(), mode);
//队列的尾节点tail为null，赋值给pred
Node 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等于null
Node 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 (;;) {
//获取当前线程节点的上一个节点 p
final Node p = node.predecessor();
//当前线程是head后紧跟的第一个节点，不直接阻塞，先让他尝试获取一次锁
if (p == head && tryAcquire(arg)) {
//如果获取成功，把当前线程节点设置为head节点
setHead(node);
//原来的head节点被GC处理掉！
p.next = null; // help GC
failed = 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) {
//获取上一个节点的waitStatus
int 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 flag
b.interrupt(this);
return;
}
}
interrupt0();
}
interrupt方法仅仅是置线程的中断状态位为中断状态，不会立马停止线程。 需要用户自己去监视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出interruptedException的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。
所以调用interrupt()时：
- 如果线程处于阻塞状态，如
sleep、wait等状态，此时监控到中断标志设置为true，那么线程将立即退出阻塞状态，并抛出一个InterruptedException异常 - 如果线程处于正常活动状态，那么只会将该线程的中断标志设置为
true，被设置中断标志的线程将继续正常运行，不受影响。
interrupted 方法
public static boolean interrupted() {
//注意：其内部调用的是：isInterrupted方法，不过入参为true
return 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传入1
public void unlock() {
//把当前的状态量state=1传入
sync.release(1);
}
//AQS的release()方法，接收传进来的状态量state = 1
public 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 = -1
int ws = node.waitStatus;
if (ws < 0)
//在这里把waitStatus = -1 置为初始状态0
compareAndSetWaitStatus(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 {
// 如果是可重入锁，+1
if (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();
}
}
}
测试结果：
完成了锁互斥性的实现
193
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
