--- category: - Java核心 - 并发编程 tag: - Java --- # 大致了解下Java的锁接口和锁 前面我们介绍了Java原生的锁——基于对象的锁，它一般是配合synchronized关键字来使用的。实际上，Java在`java.util.concurrent.locks`包下，还为我们提供了几个关于锁的类和接口。它们有更强大的功能或更高的性能。 ## synchronized的不足之处 我们先来看看`synchronized`有什么不足之处。 - 如果临界区是只读操作，其实可以多线程一起执行，但使用synchronized的话，**同一时间只能有一个线程执行**。 - synchronized无法知道线程有没有成功获取到锁 - 使用synchronized，如果临界区因为IO或者sleep方法等原因阻塞了，而当前线程又没有释放锁，就会导致**所有线程等待**。 而这些都是locks包下的锁可以解决的。 ## 锁的几种分类 锁可以根据以下几种方式来进行分类，下面我们逐一介绍。 ### 可重入锁和非可重入锁 所谓重入锁，顾名思义。就是支持重新进入的锁，也就是说这个锁支持一个**线程对资源重复加锁**。 synchronized关键字就是使用的重入锁。比如说，你在一个synchronized实例方法里面调用另一个本实例的synchronized实例方法，它可以重新进入这个锁，不会出现任何异常。 如果我们自己在继承AQS实现同步器的时候，没有考虑到占有锁的线程再次获取锁的场景，可能就会导致线程阻塞，那这个就是一个“非可重入锁”。 `ReentrantLock`的中文意思就是可重入锁。也是本文后续要介绍的重点类。 ### 公平锁与非公平锁 这里的“公平”，其实通俗意义来说就是“先来后到”，也就是FIFO。如果对一个锁来说，先对锁获取请求的线程一定会先被满足，后对锁获取请求的线程后被满足，那这个锁就是公平的。反之，那就是不公平的。 一般情况下，**非公平锁能提升一定的效率。但是非公平锁可能会发生线程饥饿（有一些线程长时间得不到锁）的情况**。所以要根据实际的需求来选择非公平锁和公平锁。 ReentrantLock支持非公平锁和公平锁两种。 ### 读写锁和排它锁 我们前面讲到的synchronized用的锁和ReentrantLock，其实都是“排它锁”。也就是说，这些锁在同一时刻只允许一个线程进行访问。 而读写锁可以在同一时刻允许多个读线程访问。Java提供了ReentrantReadWriteLock类作为读写锁的默认实现，内部维护了两个锁：一个读锁，一个写锁。通过分离读锁和写锁，使得在“读多写少”的环境下，大大地提高了性能。 > 注意，即使用读写锁，在写线程访问时，所有的读线程和其它写线程均被阻塞。 **可见，只是synchronized是远远不能满足多样化的业务对锁的要求的**。接下来我们介绍一下JDK中有关锁的一些接口和类。 ## JDK中有关锁的一些接口和类 众所周知，JDK中关于并发的类大多都在`java.util.concurrent`（以下简称juc）包下。而juc.locks包看名字就知道，是提供了一些并发锁的工具类的。前面我们介绍的AQS（AbstractQueuedSynchronizer）就是在这个包下。下面分别介绍一下这个包下的类和接口以及它们之间的关系。 ### 抽象类AQS/AQLS/AOS 这三个抽象类有一定的关系，所以这里放到一起讲。 首先我们看**AQS**（AbstractQueuedSynchronizer），之前专门有章节介绍这个类，它是在JDK 1.5 发布的，提供了一个“队列同步器”的基本功能实现。而AQS里面的“资源”是用一个`int`类型的数据来表示的，有时候我们的业务需求资源的数量超出了`int`的范围，所以在JDK 1.6 中，多了一个**AQLS**（AbstractQueuedLongSynchronizer）。它的代码跟AQS几乎一样，只是把资源的类型变成了`long`类型。 AQS和AQLS都继承了一个类叫**AOS**（AbstractOwnableSynchronizer）。这个类也是在JDK 1.6 中出现的。这个类只有几行简单的代码。从源码类上的注释可以知道，它是用于表示锁与持有者之间的关系（独占模式）。可以看一下它的主要方法： ```java // 独占模式，锁的持有者 private transient Thread exclusiveOwnerThread; // 设置锁持有者 protected final void setExclusiveOwnerThread(Thread t) { exclusiveOwnerThread = t; } // 获取锁的持有线程 protected final Thread getExclusiveOwnerThread() { return exclusiveOwnerThread; } ``` ### 接口Condition/Lock/ReadWriteLock juc.locks包下共有三个接口：`Condition`、`Lock`、`ReadWriteLock`。其中，Lock和ReadWriteLock从名字就可以看得出来，分别是锁和读写锁的意思。Lock接口里面有一些获取锁和释放锁的方法声明，而ReadWriteLock里面只有两个方法，分别返回“读锁”和“写锁”： ```java public interface ReadWriteLock { Lock readLock(); Lock writeLock(); } ``` Lock接口中有一个方法是可以获得一个`Condition`: ```java Condition newCondition(); ``` 之前我们提到了每个对象都可以用继承自`Object`的**wait/notify**方法来实现**等待/通知机制**。而Condition接口也提供了类似Object监视器的方法，通过与**Lock**配合来实现等待/通知模式。 那为什么既然有Object的监视器方法了，还要用Condition呢？这里有一个二者简单的对比： | 对比项 | Object监视器 | Condition | | ---------------------------------------------- | ----------------------------- | ----------------------------------------------------------- | | 前置条件 | 获取对象的锁 | 调用Lock.lock获取锁，调用Lock.newCondition获取Condition对象 | | 调用方式 | 直接调用，比如object.notify() | 直接调用，比如condition.await() | | 等待队列的个数 | 一个 | 多个 | | 当前线程释放锁进入等待状态 | 支持 | 支持 | | 当前线程释放锁进入等待状态，在等待状态中不中断 | 不支持 | 支持 | | 当前线程释放锁并进入超时等待状态 | 支持 | 支持 | | 当前线程释放锁并进入等待状态直到将来的某个时间 | 不支持 | 支持 | | 唤醒等待队列中的一个线程 | 支持 | 支持 | | 唤醒等待队列中的全部线程 | 支持 | 支持 | Condition和Object的wait/notify基本相似。其中，Condition的await方法对应的是Object的wait方法，而Condition的**signal/signalAll**方法则对应Object的notify/notifyAll()。但Condition类似于Object的等待/通知机制的加强版。我们来看看主要的方法： | 方法名称 | 描述 | | ---------------------- | ------------------------------------------------------------ | | await() | 当前线程进入等待状态直到被通知（signal）或者中断；当前线程进入运行状态并从await()方法返回的场景包括：（1）其他线程调用相同Condition对象的signal/signalAll方法，并且当前线程被唤醒；（2）其他线程调用interrupt方法中断当前线程； | | awaitUninterruptibly() | 当前线程进入等待状态直到被通知，在此过程中对中断信号不敏感，不支持中断当前线程 | | awaitNanos(long) | 当前线程进入等待状态，直到被通知、中断或者超时。如果返回值小于等于0，可以认定就是超时了 | | awaitUntil(Date) | 当前线程进入等待状态，直到被通知、中断或者超时。如果没到指定时间被通知，则返回true，否则返回false | | signal() | 唤醒一个等待在Condition上的线程，被唤醒的线程在方法返回前必须获得与Condition对象关联的锁 | | signalAll() | 唤醒所有等待在Condition上的线程，能够从await()等方法返回的线程必须先获得与Condition对象关联的锁 | ### ReentrantLock ReentrantLock是一个非抽象类，它是Lock接口的JDK默认实现，实现了锁的基本功能。从名字上看，它是一个”可重入“锁，从源码上看，它内部有一个抽象类`Sync`，是继承了AQS，自己实现的一个同步器。同时，ReentrantLock内部有两个非抽象类`NonfairSync`和`FairSync`，它们都继承了Sync。从名字上看得出，分别是”非公平同步器“和”公平同步器“的意思。这意味着ReentrantLock可以支持”公平锁“和”非公平锁“。 通过看这两个同步器的源码可以发现，它们的实现都是”独占“的。都调用了AOS的`setExclusiveOwnerThread`方法，所以ReentrantLock的锁是”独占“的，也就是说，它的锁都是”排他锁“，不能共享。 在ReentrantLock的构造方法里，可以传入一个`boolean`类型的参数，来指定它是否是一个公平锁，默认情况下是非公平的。这个参数一旦实例化后就不能修改，只能通过`isFair()`方法来查看。 ### ReentrantReadWriteLock 这个类也是一个非抽象类，它是ReadWriteLock接口的JDK默认实现。它与ReentrantLock的功能类似，同样是可重入的，支持非公平锁和公平锁。不同的是，它还支持”读写锁“。 ReentrantReadWriteLock内部的结构大概是这样： ```java // 内部结构 private final ReentrantReadWriteLock.ReadLock readerLock; private final ReentrantReadWriteLock.WriteLock writerLock; final Sync sync; abstract static class Sync extends AbstractQueuedSynchronizer { // 具体实现 } static final class NonfairSync extends Sync { // 具体实现 } static final class FairSync extends Sync { // 具体实现 } public static class ReadLock implements Lock, java.io.Serializable { private final Sync sync; protected ReadLock(ReentrantReadWriteLock lock) { sync = lock.sync; } // 具体实现 } public static class WriteLock implements Lock, java.io.Serializable { private final Sync sync; protected WriteLock(ReentrantReadWriteLock lock) { sync = lock.sync; } // 具体实现 } // 构造方法，初始化两个锁 public ReentrantReadWriteLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); readerLock = new ReadLock(this); writerLock = new WriteLock(this); } // 获取读锁和写锁的方法 public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; } public ReentrantReadWriteLock.ReadLock readLock() { return readerLock; } ``` 可以看到，它同样是内部维护了两个同步器。且维护了两个Lock的实现类ReadLock和WriteLock。从源码可以发现，这两个内部类用的是外部类的同步器。 ReentrantReadWriteLock实现了读写锁，但它有一个小弊端，就是在“写”操作的时候，其它线程不能写也不能读。我们称这种现象为“写饥饿”，将在后文的StampedLock类继续讨论这个问题。 ### StampedLock `StampedLock`类是在Java 8 才发布的，也是Doug Lea大神所写，有人号称它为锁的性能之王。它没有实现Lock接口和ReadWriteLock接口，但它其实是实现了“读写锁”的功能，并且性能比ReentrantReadWriteLock更高。StampedLock还把读锁分为了“乐观读锁”和“悲观读锁”两种。 前面提到了ReentrantReadWriteLock会发生“写饥饿”的现象，但StampedLock不会。它是怎么做到的呢？它的核心思想在于，**在读的时候如果发生了写，应该通过重试的方式来获取新的值，而不应该阻塞写操作。这种模式也就是典型的无锁编程思想，和CAS自旋的思想一样**。这种操作方式决定了StampedLock在读线程非常多而写线程非常少的场景下非常适用，同时还避免了写饥饿情况的发生。 这里篇幅有限，就不介绍StampedLock的源码了，只是分析一下官方提供的用法（在JDK源码类声明的上方或Javadoc里可以找到）。 ```java class Point { private double x, y; private final StampedLock sl = new StampedLock(); // 写锁的使用 void move(double deltaX, double deltaY) { long stamp = sl.writeLock(); // 获取写锁 try { x += deltaX; y += deltaY; } finally { sl.unlockWrite(stamp); // 释放写锁 } } // 乐观读锁的使用 double distanceFromOrigin() { long stamp = sl.tryOptimisticRead(); // 获取乐观读锁 double currentX = x, currentY = y; if (!sl.validate(stamp)) { // //检查乐观读锁后是否有其他写锁发生，有则返回false stamp = sl.readLock(); // 获取一个悲观读锁 try { currentX = x; currentY = y; } finally { sl.unlockRead(stamp); // 释放悲观读锁 } } return Math.sqrt(currentX * currentX + currentY * currentY); } // 悲观读锁以及读锁升级写锁的使用 void moveIfAtOrigin(double newX, double newY) { 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(); // 强制获取写锁 } } } finally { sl.unlock(stamp); // 释放所有锁 } } } ``` > 乐观读锁的意思就是先假定在这个锁获取期间，共享变量不会被改变，既然假定不会被改变，那就不需要上锁。在获取乐观读锁之后进行了一些操作，然后又调用了validate方法，这个方法就是用来验证tryOptimisticRead之后，是否有写操作执行过，如果有，则获取一个悲观读锁，这里的悲观读锁和ReentrantReadWriteLock中的读锁类似，也是个共享锁。 可以看到，StampedLock获取锁会返回一个`long`类型的变量，释放锁的时候再把这个变量传进去。简单看看源码： ```java // 用于操作state后获取stamp的值 private static final int LG_READERS = 7; private static final long RUNIT = 1L; //0000 0000 0001 private static final long WBIT = 1L << LG_READERS; //0000 1000 0000 private static final long RBITS = WBIT - 1L; //0000 0111 1111 private static final long RFULL = RBITS - 1L; //0000 0111 1110 private static final long ABITS = RBITS | WBIT; //0000 1111 1111 private static final long SBITS = ~RBITS; //1111 1000 0000 // 初始化时state的值 private static final long ORIGIN = WBIT << 1; //0001 0000 0000 // 锁共享变量state private transient volatile long state; // 读锁溢出时用来存储多出的读锁 private transient int readerOverflow; ``` StampedLock用这个long类型的变量的前7位（LG_READERS）来表示读锁，每获取一个悲观读锁，就加1（RUNIT），每释放一个悲观读锁，就减1。而悲观读锁最多只能装128个（7位限制），很容易溢出，所以用一个int类型的变量来存储溢出的悲观读锁。 写锁用state变量剩下的位来表示，每次获取一个写锁，就加0000 1000 0000（WBIT）。需要注意的是，**写锁在释放的时候，并不是减WBIT，而是再加WBIT**。这是为了**让每次写锁都留下痕迹**，解决CAS中的ABA问题，也为**乐观锁检查变化**validate方法提供基础。 乐观读锁就比较简单了，并没有真正改变state的值，而是在获取锁的时候记录state的写状态，在操作完成后去检查state的写状态部分是否发生变化，上文提到了，每次写锁都会留下痕迹，也是为了这里乐观锁检查变化提供方便。 总的来说，StampedLock的性能是非常优异的，基本上可以取代ReentrantReadWriteLock的作用。 --- >编辑：沉默王二，内容大部分来源以下三个开源仓库： >- [深入浅出 Java 多线程](http://concurrent.redspider.group/) >- [并发编程知识总结](https://github.com/CL0610/Java-concurrency) >- [Java八股文](https://github.com/CoderLeixiaoshuai/java-eight-part)