java 并发 同步_Java并发——同步组件

特指Java.util.concurrent(JUC)包下的同步组件，包括AbstractQuenedSynchronizer(AQS)、ReentrantLock、CyclicBarrier等。

关键词AQS基本概念

核心同步参数

两种资源共享方式Exclusive(独占)

Share(共享)

底层原理模板方法

示例：ReentrantLock实现

示例：CountDownLatch实现

ReentrantLock公平锁和非公平锁

ReentrantReadWriteLock基本概念

实现方式

注意要点

Semaphore

CyclicBarrier和CountDownLatch基本原理

线程等待逻辑

比较CyclicBarrier与CountDownLatch

1.AQS

1.1基本概念

AQS 是一个用来构建锁和同步器的框架，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask 等等皆是基于 AQS 的。当然，我们自己也能利用 AQS 非常轻松容易地构造出符合我们自己需求的同步器。

AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系)。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点(Node)来实现锁的分配。

1.2核心同步参数

AQS 使用一个 int 成员变量来表示同步状态，通过内置的 FIFO 队列来完成获取资源线程的排队工作。AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改。

private volatile int state;//共享变量，使用volatile修饰保证线程可见性

状态信息通过 protected 类型的getState，setState，compareAndSetState进行操作

//返回同步状态的当前值protected final int getState() {

return state;

}

// 设置同步状态的值protected final void setState(int newState) {

state = newState;

}

//原子地(CAS操作)将同步状态值设置为给定值update如果当前同步状态的值等于expect(期望值)protected final boolean compareAndSetState(int expect, int update) {

return unsafe.compareAndSwapInt(this, stateOffset, expect, update);

}

1.3两种资源共享方式

1.3.1Exclusive(独占)

只有一个线程能执行，如 ReentrantLock。又可分为公平锁和非公平锁,ReentrantLock 同时支持两种锁。公平锁：按照线程在队列中的排队顺序，先到者先拿到锁

非公平锁：当线程要获取锁时，先通过两次 CAS 操作去抢锁，如果没抢到，当前线程再加入到队列中等待唤醒。

1.3.2Share(共享)

多个线程可同时执行，如 Semaphore/CountDownLatch。

ReentrantReadWriteLock 可以看成是组合式，因为 ReentrantReadWriteLock 也就是读写锁允许多个线程同时对某一资源进行读。

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等)，AQS 已经在上层已经帮我们实现好了。

1.4底层原理

1.4.1模板方法

AQS 使用了模板方法模式，自定义同步器时需要重写下面几个 AQS 提供的模板方法：

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

1.4.2示例：ReentrantLock实现

state 初始化为 0，表示未锁定状态。A 线程 lock()时，会调用 tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire()时就会失败，直到 A 线程 unlock()到 state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的(state 会累加)，这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。

1.4.3示例：CountDownLatch实现

任务分为 N 个子线程去执行，state 也初始化为 N(注意 N 要与线程个数一致)。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state 会 CAS(Compare and Swap)减 1。等到所有子线程都执行完后(即 state=0)，会 unpark()主调用线程，然后主调用线程就会从 await()函数返回，继续后余动作。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

2.ReentrantLock

2.1公平锁和非公平锁

公平锁和非公平锁只有两处不同：

非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。

非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了(state == 0)，非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。

3ReentrantReadWriteLock

3.1基本概念

ReentrantReadWriteLock 分为读锁和写锁两个实例，读锁是共享锁，可被多个线程同时使用，写锁是独占锁。持有写锁的线程可以继续获取读锁，反之不行。

内部维护了ReadLock和WriteLock两个锁，其中ReadLock 使用了共享模式，WriteLock 使用了独占模式。

3.2实现方式

读写锁 ReentrantReadWriteLock 中是怎么使用 state 的呢？答案是将 state 这个 32 位的 int 值分为高 16 位和低 16位，分别用于共享模式和独占模式。

3.3注意要点

不要先获取读锁然后获取写锁，可能产生死锁问题。

4.Semaphore

synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。 Semaphore也支持公平与非公平。

5.CyclicBarrier和CountDownLatch

5.1基本原理

CyclicBarrier字面意思是“可重复使用的栅栏”，它是 ReentrantLock 和 Condition 的组合使用。

CountDownLatch 基于 AQS 的共享模式的使用，而 CyclicBarrier 基于 Condition 来实现的。

在CyclicBarrier类的内部有一个计数器，每个线程在到达屏障点的时候都会调用await方法将自己阻塞，此时计数器会减1，当计数器减为0的时候所有因调用await方法而被阻塞的线程将被唤醒。这就是实现一组线程相互等待的原理。

//同步操作锁private final ReentrantLock lock = new ReentrantLock();

//线程拦截器private final Condition trip = lock.newCondition();

//每次拦截的线程数private final int parties;

//换代前执行的任务private final Runnable barrierCommand;

//表示栅栏的当前代private Generation generation = new Generation();

//计数器private int count;

//静态内部类Generationprivate static class Generation {

boolean broken = false;

}

parties表示每次拦截的线程数，该值在构造时进行赋值。count是内部计数器，它的初始值和parties相同，以后随着每次await方法的调用而减1，直到减为0就将所有线程唤醒。CyclicBarrier有一个静态内部类Generation，该类的对象代表栅栏的当前代，就像玩游戏时代表的本局游戏，利用它可以实现循环等待。barrierCommand表示换代前执行的任务，当count减为0时表示本局游戏结束，需要转到下一局。在转到下一局游戏之前会将所有阻塞的线程唤醒，在唤醒所有线程之前你可以通过指定barrierCommand来执行自己的任务。

5.2线程等待逻辑

如果当前线程不是最后一个调用await方法的线程，则它会一直处于等待状态，除非发生以下情况：

最后一个线程到达，即index == 0

某个参与线程等待超时(打翻栅栏breakBarrier)

某个参与线程被中断(打翻栅栏breakBarrier)

调用了CyclicBarrier的reset()方法。该方法会将屏障重置为初始状态(打翻栅栏breakBarrier并切换下一代nextGeneration)

如果count值已经为0,那就由最后一个调用await的线程来执行barrierAction，然后nextGeneration(唤醒线程，重设代次)

5.3比较CyclicBarrier与CountDownLatch

这两个类都可以实现一组线程在到达某个条件之前进行等待，它们内部都有一个计数器，当计数器的值不断的减为0的时候所有阻塞的线程将会被唤醒。

有区别的是CyclicBarrier的计数器由自己控制，而CountDownLatch的计数器则由使用者来控制，在CyclicBarrier中线程调用await方法不仅会将自己阻塞还会将计数器减1，而在CountDownLatch中线程调用await方法只是将自己阻塞而不会减少计数器的值。

另外，CountDownLatch只能拦截一轮，而CyclicBarrier可以实现循环拦截。一般来说用CyclicBarrier可以实现CountDownLatch的功能，而反之则不能，例如上面的赛马程序就只能使用CyclicBarrier来实现。总之，这两个类的异同点大致如此，至于何时使用CyclicBarrier，何时使用CountDownLatch，还需要读者自己去拿捏。

除此之外，CyclicBarrier还提供了：reset()、getNumberWaiting()、isBroken()等比较有用的方法。

参考资料：