标签：JUC Java Lock ReentrantLock 获取 线程 lock Condition
一、Lock （JUC锁）
JUC 锁位于java.util.concurrent.locks包下，为锁和等待条件提供一个框架，它不同于内置同步和监视器。
CountDownLatch，CyclicBarrier 和 Semaphore 不在包中属于并发编程中的工具类，但也是通过 AQS（后面会讲） 来实现的。因此，我也将它们归纳到 JUC 锁中进行介绍。
| 1、Lock | Lock实现提供了比使用synchronized方法和语句可获得的更广泛的锁定操作。 |
| 2、ReentrantLock | 一个可重入的互斥锁，它具有与隐式锁synchronized相同的一些基本行为和语义，但功能更强大。 |
| 3、AQS类 | AbstractOwnableSynchronizer/AbstractQueuedSynchronizer/AbstractQueuedLongSynchronizer AbstractQueuedSynchronizer 就是被称之为AQS的类，为实现依赖于先进先出 (FIFO) 等待队列的阻塞锁和相关同步器（信号量、事件，等等）提供一个框架。ReentrantLock，ReentrantReadWriteLock，CountDownLatch，CyclicBarrier和Semaphore等这些类都是基于AQS类实现的。 AbstractOwnableSynchronizer是可以由线程以独占方式拥有的同步器。 |
| 4、Condition | Condition又称等待条件，它实现了对锁更精确的控制。 Condition中的await()方法相当于Object的wait()方法，Condition中的signal()方法相当于Object的notify()方法，Condition中的signalAll()相当于Object的notifyAll()方法。 不同的是，Object中的wait(),notify(),notifyAll()方法是和synchronized组合使用的；而Condition需要与Lock组合使用。 |
| 5、ReentrantReadWriteLock | ReentrantReadWriteLock维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。 |
| 6、LockSupport | 用来创建锁和其他同步类的基本线程阻塞原语。 |
| 7、CountDownLatch | 一个同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待。 |
| 8、CyclicBarrier | 一个同步辅助类，它允许一组线程互相等待，直到到达某个公共屏障点。 |
| 9、Semaphore | 一个计数信号量。从概念上讲，信号量维护了一个许可集。Semaphore通常用于限制可以访问某些资源的线程数目。 |
二、Lock与ReentrantLock
1、概述
Java中的锁有两种，synchronized与Lock。因为使用synchronized并不需要显示地加锁与解锁，所以往往称synchronized为隐式锁，而使用Lock时则相反，所以一般称Lock为显示锁。synchronized修饰方法或语句块，所有锁的获取和释放都必须出现在一个块结构中。当需要灵活地获取或释放锁时，synchronized显然是不符合要求的。Lock接口的实现允许锁在不同的范围内获取和释放，并支持以任何顺序获取和释放多个锁。一句话，Lock实现比synchronized更灵活。但凡事有利就有弊，不使用块结构锁就失去了使用synchronized修饰方法或语句时会出现的锁自动释放功能，在大多数情况下，Lock实现需要手动释放锁。除了更灵活之外，Lock还有以下优点：
- Lock 实现提供了使用 synchronized 方法和语句所没有的其他功能，包括提供了一个非块结构的获取锁尝试
tryLock()、一个获取可中断锁的尝试lockInterruptibly()和一个获取超时失效锁的尝试tryLock(long, TimeUnit)。 - Lock 类还可以提供与隐式监视器锁完全不同的行为和语义，如保证排序、非重入用法或死锁检测。如果某个实现提供了这样特殊的语义，则该实现必须对这些语义加以记录。
ReentrantLock是一个可重入的互斥锁。顾名思义，“互斥锁”表示在某一时间点只能被同一线程所拥有。“可重入”表示锁可被某一线程多次获取。当然 synchronized 也是可重入的互斥锁。当锁没有被某一线程占有时，调用 lock() 方法的线程将成功获取锁。可以使用isHeldByCurrentThread()和 getHoldCount()方法来判断当前线程是否拥有该锁。
ReentrantLock既可以是公平锁又可以是非公平锁。当此类的构造方法 ReentrantLock(boolean fair) 接收true作为参数时，ReentrantLock就是公平锁，线程依次排队获取公平锁，即锁将被等待最长时间的线程占有。与默认情况（使用非公平锁）相比，使用公平锁的程序在多线程环境下效率比较低。而且公平锁不能保证线程调度的公平性，tryLock方法可在锁未被其他线程占用的情况下获得该锁。
2、API
1、构造方法
//创建一个 ReentrantLock 的实例。
ReentrantLock()
//创建一个具有给定公平策略的 ReentrantLock。
ReentrantLock(boolean fair) 2、方法摘要
int getHoldCount()
//查询当前线程保持此锁的次数。
protected Thread getOwner()
//返回目前拥有此锁的线程，如果此锁不被任何线程拥有，则返回 null。
protected Collection<Thread> getQueuedThreads()
//返回一个 collection，它包含可能正等待获取此锁的线程。
int getQueueLength()
//返回正等待获取此锁的线程估计数。
protected Collection<Thread> getWaitingThreads(Condition condition)
//返回一个 collection，它包含可能正在等待与此锁相关给定条件的那些线程。
int getWaitQueueLength(Condition condition)
//返回等待与此锁相关的给定条件的线程估计数。
boolean hasQueuedThread(Thread thread)
//查询给定线程是否正在等待获取此锁。
boolean hasQueuedThreads()
//查询是否有些线程正在等待获取此锁。
boolean hasWaiters(Condition condition)
//查询是否有些线程正在等待与此锁有关的给定条件。
boolean isFair()
//如果此锁的公平设置为 true，则返回 true。
boolean isHeldByCurrentThread()
//查询当前线程是否保持此锁。
boolean isLocked()
//查询此锁是否由任意线程保持。
void lock()
//获取锁。
void lockInterruptibly()
//如果当前线程未被中断，则获取锁。
Condition newCondition()
//返回用来与此 Lock 实例一起使用的 Condition 实例。
String toString()
//返回标识此锁及其锁定状态的字符串。
boolean tryLock()
//仅在调用时锁未被另一个线程保持的情况下，才获取该锁。
boolean tryLock(long timeout, TimeUnit unit)
//如果锁在给定等待时间内没有被另一个线程保持，且当前线程未被中断，则获取该锁。
void unlock()
//试图释放此锁。3、代码
1、典型的代码
class X {
private final ReentrantLock lock = new ReentrantLock();
// ...
public void m() {
lock.lock(); // block until condition holds
try {
// ... method body
} finally {
lock.unlock()
}
}
}2、买票
public class SellTickets {
public static void main(String[] args) {
TicketsWindow tw1 = new TicketsWindow();
Thread t1 = new Thread(tw1, "一号窗口");
Thread t2 = new Thread(tw1, "二号窗口");
t1.start();
t2.start();
}
}
class TicketsWindow implements Runnable {
private int tickets = 1;
private final ReentrantLock lock = new ReentrantLock();
@Override
public void run() {
while (true) {
lock.lock();
try {
if (tickets > 0) {
System.out.println(Thread.currentThread().getName()
+ "还剩余票:" + tickets + "张");
--tickets;
System.out.println(Thread.currentThread().getName()
+ "卖出一张火车票,还剩" + tickets + "张");
} else {
System.out.println(Thread.currentThread().getName()
+ "余票不足,暂停出售!");
try {
Thread.sleep(1000 * 60);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally {
lock.unlock();
}
}
}
}4、总结
- 与synchronized 相比ReentrantLock的使用更灵活。Lock接口的实现允许锁在不同的范围内获取和释放，并支持以任何顺序获取和释放多个锁。
- ReentrantLock具有与使用 synchronized 相同的一些基本行为和语义，但功能更强大。包括提供了一个非块结构的获取锁尝试
tryLock()、一个获取可中断锁的尝试lockInterruptibly()和一个获取超时失效锁的尝试tryLock(long, TimeUnit)。 - ReentrantLock 具有 synchronized 所没有的许多特性，比如时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者轮询锁。
- ReentrantLock 可伸缩性强，应当在高度争用的情况下使用它。
三、AQS
1、概述
谈到 ReentrantLock，不得不谈 AbstractQueuedSynchronizer（AQS）！AQS，AbstractQueuedSynchronizer的缩写（抽象的队列式的同步器），是 JUC 的核心。AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock、Semaphore、CountDownLatch。
它维护了一个 volatile int state（代表共享资源）和一个 FIFO 线程等待队列（多线程争用资源被阻塞时会进入此队列）
这里 volatile 是核心关键词，具体volatile的语义，在此不述。state的访问方式有三种:
- getState()
- setState()
- compareAndSetState()
AQS定义两种资源共享方式：Exclusive（独占锁，只有一个线程能执行，如 ReentrantLock）和 Share（共享锁，多个线程可同时执行，如Semaphore/CountDownLatch）。AQS的子类（锁或者同步器）实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：
- isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
- tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。
以 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减1。等到所有子线程都执行完后(即state=0)，会 unpark() 主线程，然后主线程就会从 await() 函数返回，继续后余动作。
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现 获取-释放资源 tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如 ReentrantReadWriteLock。
2、总结
在AQS的设计中，在父类AQS中实现了对 等待队列的默认实现，子类中几乎不用修改该部分功能。而state在子类中根据需要被赋予了不同的意义，子类通过对state的不同操作来提供不同的同步器功能，进而对封装的工具类提供不同的功能。AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用就将 暂时获取不到锁的线程加入到队列中（CLH队列 自旋 双向队列），AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。
四、Condition
在任务协作中，关键问题是任务之间的通信，除了 同步监视器之外，Java 1.5 之后还提供了 Lock 跟 Condition 组合来实现线程之间的通信
1、与Object监视器监视器方法的比较
| 对比项 | Condition | Object监视器 |
|---|---|---|
| 使用条件 | 获取锁 | 获取锁，创建Condition对象 |
| 等待队列的个数 | 一个 | 多个 |
| 是否支持通知指定等待队列 | 支持 | 不支持 |
| 是否支持当前线程释放锁进入等待状态 | 支持 | 支持 |
| 是否支持当前线程释放锁并进入超时等待状态 | 支持 | 支持 |
| 是否支持当前线程释放锁并进入等待状态直到指定最后期限 | 支持 | 不支持 |
| 是否支持唤醒等待队列中的一个任务 | 支持 | 支持 |
| 是否支持唤醒等待队列中的全部任务 | 支持 | 支持 |
2、API
void await()
//造成当前线程在接到信号或被中断之前一直处于等待状态。
boolean await(long time, TimeUnit unit)
//造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
long awaitNanos(long nanosTimeout)
//造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
void awaitUninterruptibly()
//造成当前线程在接到信号之前一直处于等待状态。
boolean awaitUntil(Date deadline)
//造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。
void signal()
//唤醒一个等待线程。
void signalAll()
//唤醒所有等待线程。3、演示下Condition是如何更精细地控制线程的休眠与唤醒的。
public class BoundedBuffer {
final Lock lock = new ReentrantLock();//锁
final Condition notFull = lock.newCondition();//写条件
final Condition notEmpty = lock.newCondition();//读条件
final Object[] items = new Object[100];
int putptr, takeptr, count;
//存数据
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)//如果队列已满
notFull.await();//阻塞写线程
items[putptr] = x;
if (++putptr == items.length)
putptr = 0;
++count;
notEmpty.signal();//唤醒读线程
} finally {
lock.unlock();
}
}
//写数据
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)//如果队列已空
notEmpty.await();//阻塞读线程
Object x = items[takeptr];
if (++takeptr == items.length)
takeptr = 0;
--count;
notFull.signal();//唤醒写线程
return x;
} finally {
lock.unlock();
}
}
}这是一个有界的缓冲区，支持put(Object)与take()方法。put(Object)负责向缓冲区中存数据，take负责从缓冲区中读数据。在多线程环境下，调用put(Object)方法，当缓冲区已满时，会阻塞写线程，如果缓冲区不满，则写入数据，并唤醒读线程。调用take()方法时，当缓冲区为空，会阻塞读线程，如果缓冲区不空，则读取数据，并唤醒写线程。
这就是多个Condition的强大之处，假设缓存队列已满，那么阻塞的肯定是写线程，唤醒的肯定是读线程，相反，阻塞的肯定是读线程，唤醒的肯定是写线程。如果采用Object类中的wait(), notify(), notifyAll()实现该缓冲区，当向缓冲区写入数据之后需要唤醒读线程时，通过notify()或notifyAll()无法明确的指定唤醒读线程，而只能通过notifyAll唤醒所有线程，但notifyAll无法区分唤醒的线程是读线程，还是写线程。 如果唤醒的是写线程，那么线程刚被唤醒，又被阻塞了，这样就降低了效率。
五、ReentrantReadWriteLock
1、概述
ReentrantLock是互斥锁。与互斥锁相对应的是共享锁。ReadWriteLock就是一种共享锁 ，ReentrantReadWriteLock是支持与 ReentrantLock 类似语义的 ReadWriteLock 实现。ReadWriteLock 维护了两个锁，读锁和写锁，所以一般称其为读写锁。写锁是独占的。读锁是共享的，如果没有写锁，读锁可以由多个线程共享。与互斥锁相比，虽然一次只能有一个写线程可以修改共享数据，但大量读线程可以同时读取共享数据，所以，在共享数据很大，且读操作远多于写操作的情况下，读写锁值得一试。
ReadWriteLock源码如下：
public interface ReadWriteLock {
//返回用于读取操作的锁。
Lock readLock();
//返回用于写入操作的锁。
Lock writeLock();
}从源码中可以看到，ReadWriteLock并不是Lock的子接口。所以ReadWriteLock并没有Lock的那些特性。
2、使用场景
在使用某些种类的Collection时，可以使用ReentrantReadWriteLock来提高并发性。通常，在预期collection很大，读取者线程访问它的次数多于写入者线程，并且entail操作的开销高于同步开销时，这很值得一试。例如，以下是一个使用 TreeMap的类，预期它很大，并且能被同时访问。
public class RWDictionary {
// TeepMap就是读的多，插入的少的场景
private final Map<String, Data> m = new TreeMap<String, Data>();
private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
//读锁
private final Lock r = rwl.readLock();
//写锁
private final Lock w = rwl.writeLock();
public Data get(String key) {
r.lock();
try {
return m.get(key);
} finally {
r.unlock();
}
}
public String[] allKeys() {
r.lock();
try {
return (String[])m.keySet().toArray();
} finally {
r.unlock();
}
}
public Data put(String key, Data value) {
w.lock();
try {
return m.put(key, value);
} finally {
w.unlock();
}
}
public void clear() {
w.lock();
try {
m.clear();
} finally {
w.unlock();
}
}
}3、特性
ReentrantReadWriteLock 具有以下特性：（有待详细介绍）
- 公平性
- 重入性
- 锁降级
- 锁获取中断
- 支持Condition
- 检测系统状态
优点
与互斥锁相比，虽然一次只能有一个写线程可以修改共享数据，但大量读线程可以同时读取共享数据。在共享数据很大，且读操作远多于写操作的情况下，ReentrantReadWriteLock值得一试。
缺点
只有当前没有线程持有读锁或者写锁时才能获取到写锁，这可能会导致写线程发生饥饿现象，即读线程太多导致写线程迟迟竞争不到锁而一直处于等待状态。StampedLock 可以解决这个问题，解决方法是如果在读的过程中发生了写操作，应该重新读而不是直接阻塞写线程。
六、StampedLock
1、概述
StampedLock是JDK1.8新增的一个锁，是对读写锁ReentrantReadWriteLock的改进。前面已经学习了ReentrantReadWriteLock，我们了解到，在共享数据很大，且读操作远多于写操作的情况下，ReentrantReadWriteLock 值得一试。但要注意的是，只有当前没有线程持有读锁或者写锁时才能获取到写锁，这可能会导致写线程发生饥饿现象，即读线程太多导致写线程迟迟竞争不到锁而一直处于等待状态。StampedLock可以解决这个问题，解决方法是如果在读的过程中发生了写操作，应该重新读而不是直接阻塞写线程。
StampedLock有三种读/写模式：写、读、乐观读。
- 写。独占锁，只有当前没有线程持有读锁或者写锁时才能获取到该锁。方法writeLock()返回一个可用于unlockWrite(long)释放锁的方法的戳记。tryWriteLock()提供不计时和定时的版本。
- 读。共享锁，如果当前没有线程持有写锁即可获取该锁，可以由多个线程获取到该锁。方法readLock()返回可用于unlockRead(long)释放锁的方法的戳记。tryReadLock()也提供不计时和定时的版本。
- 乐观读。方法tryOptimisticRead()仅当锁定当前未处于写入模式时，方法才会返回非零戳记。返回戳记后，需要调用validate(long stamp)方法验证戳记是否可用。也就是看当调用tryOptimisticRead返回戳记后到到当前时间是否有其他线程持有了写锁，如果有，返回false，否则返回true，这时就可以使用该锁了。
2、代码
StampedLock 则提供了一种乐观的读策略,这种乐观策略的锁非常类似于无锁的操作,使得乐观锁完全不会阻塞写线程
class Point {
private double x, y;
private final StampedLock sl = new StampedLock();
/**
* 改变当前坐标。
* 先获取写锁，然后对point坐标进行修改，最后释放锁。
* 该锁是排它锁，这保证了其他线程调用move函数时候会被阻塞，直到当前线程显示释放了该锁。
*/
void move(double deltaX, double deltaY) { // an exclusively locked method
long stamp = sl.writeLock();
try {
x += deltaX;
y += deltaY;
} finally {
sl.unlockWrite(stamp);
}
}
/**
* 计算当前坐标到原点的距离
*
* @return
*/
double distanceFromOrigin() {
//1.尝试获取乐观读锁，返回stamp
long stamp = sl.tryOptimisticRead();
//2.拷贝参数到本地方法栈中
double currentX = x, currentY = y;
//3.验证stamp是否有效
if (!sl.validate(stamp)) {
//4.如果stamp无效，说明得到stamp后，又有其他线程获得了写锁
//5.获取读锁
stamp = sl.readLock();
try {
//6.其他线程修改了x,y的值，为了数据的一致性，需要再次再次拷贝参数到本地方法栈中
currentX = x;
currentY = y;
} finally {
//7.释放读锁
sl.unlockRead(stamp);
}
}
//8.使用参数的拷贝来计算当前坐标到原点的距离。无论步骤3中stamp有没有验证成功
//，参数的拷贝都是当前坐标的值
return Math.sqrt(currentX * currentX + currentY * currentY);
}
/**
* 如果当前坐标为原点则移动到指定的位置
*/
void moveIfAtOrigin(double newX, double newY) { // upgrade
// 获取读锁，保证其他线程不能获取到写锁
long stamp = sl.readLock();
try {
//如果当前坐标为原点
while (x == 0.0 && y == 0.0) {
//尝试升级成写锁
long ws = sl.tryConvertToWriteLock(stamp);
//如果升级成功，更新坐标值
if (ws != 0L) {
stamp = ws;
x = newX;
y = newY;
break;
} else {//如果升级成功
sl.unlockRead(stamp);//先释放读锁
stamp = sl.writeLock();//再获取写锁
//循环while中的操作，直到成功更新坐标值
}
}
} finally {
//最后释放写锁
sl.unlock(stamp);
}
}
}3、StampedLock 原理
StampedLock的内部实现是基于CLH锁的,CLH锁是一种自旋锁,它保证没有饥饿的发生,并且可以保证FIFO(先进先出)的服务顺序.CLH锁的基本思想如下:锁维护一个等待线程队列,所有申请锁,但是没有成功的线程都记录在这个队列中,每一个节点代表一个线程,保存一个标记位(locked).用与判断当前线程是否已经释放锁;locked=true 没有获取到锁,false 已经成功释放了锁
当一个线程视图获得锁时,取得等待队列的尾部节点作为其前序节点.并使用类似如下代码判断前序节点是否已经成功释放锁:只要前序节点(pred)没有释放锁,则表示当前线程还不能继续执行,因此会自旋等待,
反之,如果前序线程已经释放锁,则当前线程可以继续执行.
释放锁时,也遵循这个逻辑,线程会将自身节点的locked位置标记位false,那么后续等待的线程就能继续执行了七、CountDownLatch、Semaphore、Exchanger、CyclicBarrier
标签：JUC,Java,Lock,ReentrantLock,获取,线程,lock,Condition 来源： https://blog.csdn.net/sanmi8276/article/details/113982934
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。