AQS原理

AQS原理

AQS 的全称是 AbstractQueuedSynchronizer。AQS是一个用来构建锁和同步器的框架。

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

Exclusive（独占）：只有一个线程能执行，如 ReentrantLock。又可分为公平锁和非公平锁：
公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
Share（共享）：多个线程可同时执行，如 CountDownLatch、Semaphore、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。
ReentrantReadWriteLock 可以看成是组合式，因为 ReentrantReadWriteLock 也就是读写锁允许多个线程同时对某一资源进行读。

AQS通过模板方法模式来自定义同步器：

在使用模板方法模式时只需要对以下几个方法重写：

protected boolean tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
protected boolean tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
protected int tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
protected boolean tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。
protected boolean isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。

除此之外，AQS 类中的其他方法都是 final ，所以无法被其他类重写。

以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程 lock() 时，会调用 tryAcquire() 独占该锁并将 state+1 。此后，其他线程再 tryAcquire() 时就会失败，直到 A 线程 unlock() 到 state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。
再以 CountDownLatch 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown() 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 state=0 )，会 unpark() 主调用线程，然后主调用线程就会从 await() 函数返回，继续后余动作。

同步队列（CLH）

同步器通过同步队列来同步状态。同步队列是一个FIFO的双向链表。当线程获取同步状态失败后，同步器会把当前线程及同步状态等信息构成一个节点添加到同步队列中，同时阻塞该线程；首节点是获取同步状态成功的节点，当首节点释放同步状态时，会唤醒其后继节点，其后继节点获取同步状态成功并成为首节点。
在同步器中，有两个状态，一个叫做 state，一个叫做 waitStatus，两者是完全不同的概念：

1. state 是锁的状态，是 int 类型，子类继承 AQS 时，都是要根据 state 字段来判断有无得到锁，比如当前同步器状态是 0，表示可以获得锁，当前同步器状态是 1，表示锁已经被其他线程持有，当前线程无法获得锁；
2. waitStatus 是节点（Node）的状态，种类很多，一共有初始化 (0)、CANCELLED (1)、SIGNAL (-1)、CONDITION (-2)、PROPAGATE (-3)。

 // CANCELLED：由于超时或中断，此节点被取消。节点一旦被取消了就不会再改变状态。特别是，取消节点的线程不会再阻塞。
static final int CANCELLED =  1;
// SIGNAL:此节点后面的节点已（或即将）被阻止（通过park），因此当前节点在释放或取消时必须断开后面的节点
// 为了避免竞争，acquire方法时前面的节点必须是SIGNAL状态，然后重试原子acquire，然后在失败时阻塞。
static final int SIGNAL    = -1;
// 此节点当前在条件队列中。标记为CONDITION的节点会被移动到一个特殊的条件等待队列（此时状态将设置为0），直到条件时才会被重新移动到同步等待队列 。（此处使用此值与字段的其他用途无关，但简化了机制。）
static final int CONDITION = -2;
//传播：应将releaseShared传播到其他节点。这是在doReleaseShared中设置的（仅适用于头部节点），以确保传播继续，即使此后有其他操作介入。
static final int PROPAGATE = -3;

//0:以上数值均未按数字排列以简化使用。非负值表示节点不需要发出信号。所以，大多数代码不需要检查特定的值，只需要检查符号。
//对于正常同步节点，该字段初始化为0；对于条件节点，该字段初始化为条件。它是使用CAS修改的（或者在可能的情况下，使用无条件的volatile写入）。

Semaphore, CyclicBarrier, CountDownLatch

CountDownLatch(倒计时器)

CountDownLatch 的作用就是 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。之前在项目中，有一个使用多线程读取多个文件处理的场景，我用到了 CountDownLatch,
具体场景是下面这样的：

我们要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是我们需要返回给用户的时候将这几个文件的处理的结果进行统计整理。

为此我们定义了一个线程池和 count 为 6 的CountDownLatch对象 。使用线程池处理读取任务，每一个线程处理完之后就将 count-1，调用CountDownLatch对象的 await()方法,直到所有文件读取完之后，才会接着执行后面的逻辑。

CyclicBarrier（循环栅栏）

它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier 默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用 await() 方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

CountDownLatch 和 CyclicBarrier 的区别

CountDownLatch 和 CyclicBarrier 都能够实现线程之间的等待，只不过它们侧重点不同：
● CountDownLatch 一般用于某个线程 A 等待若干个其他线程执行完任务之后，它才执行。
● CyclicBarrier 一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行。

Semaphore(信号量)

• 允许多个线程同时访问： synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。
• 信号量主要用于两个目的：一个是用于多个共享资源的互斥使用，另一个用于并发线程数控制。
  通过acquire()和release()来控制线程对资源的访问。

总结

CountDownLatch 和 CyclicBarrier 都能够实现线程之间的等待，只不过它们侧重点不同；CountDownLatch 一般用于某个线程 A 等待若干个其他线程执行完任务之后，它才执行；
而 CyclicBarrier 一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行；
另外，CountDownLatch 是不能够重用的，而CyclicBarrier 是可以重用的。
Semaphore 其实和锁有点类似，它一般用于控制对某组资源的访问权限。

synchronized 和 ReentrantLock 的区别

1. 两者都是可重入锁
2. synchronized是 JVM 层面，底层是通过 monitor 对象来实现，wait/notify 等方法都依赖于 monitor 对象。而 ReentrantLock 是AQS接口的实现，是 API 层面的锁。
3. synchronized 不需要用户手动释放锁，ReentrantLock 需要手动释放锁，不然可能导致死锁。
4. ReentrantLock 增加了一些高级功能：
   ○ ReentrantLock 提供了一种能够中断正在等待的线程的机制。
   ○ ReentrantLock 可以指定锁是公平的还是不公平的。
   ○ ReentrantLock 可以精准唤醒某个线程，而synchronized只能全部或者随机唤醒。