4 Java中的锁

Java中的锁

Lock接口

锁是用来控制多个线程访问共享资源的方式,一般来说，一个锁能够防止多个线程同时访问共享资源(但是有些锁可以允许多个线程并发的访问共享资源,比如读写锁)。在Lock接口出现之前,Java程序是靠synchronized关键字实现锁功能的,而Java SE 5之后，并发包中新增了Lock接口(以及相关实现类)用来实现锁功能,它提供了与synclronized关键字类似的同步功能，只是在使用时需要显式地获取和释放锁。虽然它缺少了(通过synchronized块或者方法所提供的)隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种synclronized关键字所不具备的同步特性。

使用synchronized关键字将会隐式地获取锁,但是它将锁的获取和释放固化了，也就是先获取再释放。当然,这种方式简化了同步的管理,可是扩展性没有显式的锁获取和释放来的好。

Lock的使用也很简单,代码清单5-1是Lock的使用的方式。

在finally块中释放锁，目的是保证在获取到锁之后，最终能够被释放。

不要将获取锁的过程写在try块中，因为如果在获取锁(自定义锁的实现)时发生了异常，异常抛出的同时，也会导致锁无故释放。

Lock接口提供的synclhronized关键字所不具备的主要特性如表5-1所示。

Lock是一个接口，它定义了锁获取和释放的基本操作，Lock的API如表5-2所示。

这里先简单介绍一下Lock接口的API，随后会详细介绍同步器
AbstractQueuedSynchronizer 以及常用 Lock 接口的实现 ReentrantLock 。 Lock 接口的实现基本都是 通过聚合了一个同步器的子类来完成线程访问控制的。

队列同步器

队列同步器AbstractQueuedSynchronizer(以下简称同步器)，是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。

同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态,在抽象方法的实现过程中免不了要对同步状态进行更改,这时就需要使用同步器提供的3个方法(getState()、 setState(int newState)和compareAndSetState(int expect,int update))来进行操作，因为它们能够保证状态的改变是安全的。

子类推荐被定义为自定义同步组件的静态内部类，同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用。

同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件(ReentrantLock、ReentrantReadWriteLock和CouutDownLatch等)。

同步器是实现锁(也可以是任意同步组件)的关键,在锁的实现中聚合同步器，利用同步器实现锁的语义。

可以这样理解二者之间的关系：

• 锁是面向使用者的，它定义了使用者与锁交互的接口(比如可以允许两个线程并行访问),隐藏了实现细节;
• 同步器面向的是锁的实现者,它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。
• 锁和同步器很好地隔离了使用者和实现者所需关注的领域。

队列同步器的接口与示例

同步器的设计是基于模板方法模式的，也就是说，使用者需要继承同步器并重写指定的方法,随后将同步器组合在自定义同步组件的实现中,并调用同步器提供的模板方法,而这些模板方法将会调用使用者重写的方法。

重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。

• getState()：获取当前同步状态（加锁or未加锁）。
• setState(int newState)：设置当前同步状态。
• compareAndSetState(int expect, int update)：使用CAS设置当前状态，该方法能够保证状态设置的原子性。

同步器可重写的方法与描述如表5-3所示。

顾名思义，独占锁就是在同一时刻只能有一个线程获取到锁,而其他获取锁的线程只能处于同步队列中等待,只有获取锁的线程释放了锁,后继的线程才能够获取锁，如代码清单5-2所示。

上述示例中,独占锁Mtutex是一个自定义同步组件,它在同一时刻只允许一个线程占有锁。Mutex中定义了一个静态内部类,该内部类继承了同步器并实现了独占式获取和释放同步状态。在tryAcquire(int acquires)方法中，如果经过CAS设置成功(同步状态设置为1),则代表获取了同步状态,而在tryRelease(int releases)方法中只是将同步状态重置为0。用户使用Mutex时并不会直接和内部同步器的实现打交道,而是调用Mutex提供的方法，在Mutex的实现中，以获取锁的lock)方法为例,只需要在方法实现中调用同步器的模板方法acquire(int args)即可，当前线程调用该方法获取同步状态失败后会被加入到同步队列中等待,这样就大大降低了实现一个可靠自定义同步组件的门槛。

队列同步器的实现分析

接下来将从实现角度分析同步器是如何完成线程同步的,主要包括：同步队列、独占式同步状态获取与释放、共享式同步状态获取与释放以及超时获取同步状态等同步器的核心数据结构与模板方法。

1.同步队列

同步器依赖内部的同步队列(一个FIFO双向队列)来完成同步状态的管理，当前线程获取同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点(Node)并将其加人同步队列，同时会阻塞当前线程,当同步状态释放时，会把首节点中的线程唤醒,使其再次尝试获取同步状态。

同步队列中的节点(Node)用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点，节点的属性类型与名称以及描述如表5-5所示。

• AQS加入节点是线程安全的（基于CAS操作）
• AQS设置头结点不需要CAS操作，因为只有一个线程（首线程）能获取到同步状态（锁）
  • 在图5-1中,同步器包含了两个节点类型的引用，一个指向头节点,而另一个指向尾节点。试想一下，当一个线程成功地获取了同步状态(或者锁)，其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中,而这个加入队列的过程必须要保证线程安全,因此，同步器提供了一个基于CAS的设置尾节点的方法:compareAndSetTail(Node expect,Node update)，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。

同步器将节点加入到同步队列的过程如图5-2所示。

同步队列遵循FIFO，首节点是获取同步状态成功的节点，首节点的线程在释放同步状态时，将会唤醒后继节点,而后继节点将会在获取同步状态成功时将自己设置为首节点，该过程如图5-3所示。

在图5-3中，设置首节点是通过获取同步状态成功的线程来完成的，由于只有一个线程能够成功获取到同步状态，因此设置头节点的方法并不需要使用CAS来保证，它只需要将首节点设置成为原首节点的后继节点并断开原首节点的next引用即可。

2.独占式同步状态获取与释放

通过调用同步器的acquire(int arg)方法可以获取同步状态，该方法对中断不敏感，也就是由于线程获取同步状态失败后进入同步队列中，后续对线程进行中断操作时，线程不会从同步队列中移出。

上述代码主要完成了同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待的相关工作，其主要逻辑是:首先调用自定义同步器实现的tryAcquire(int arg)方法,该方法保证线程安全的获取同步状态，如果同步状态获取失败,则构造同步节点(独占式
Node.EXCLUSIVE,同一时刻只能有一个线程成功获取同步状态)并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部,最后调用acquireQueued(Node node, int arg)方法,使得该节点以“死循环””的方式获取同步状态。如果获取不到则阻塞节点中的线程,而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞线程被中断来实现。

下面分析一下相关工作。首先是节点的构造以及加入同步队列,如代码清单5-4所示。

上述代码通过使用compareAndSetTail(Node expect,Node update)方法来确保节点能够被线程安全添加。试想一下:如果使用一个普通的LinkedList来维护节点之间的关系，那么当一个线程获取了同步状态，而其他多个线程由于调用tryAcquire(int arg)方法获取同步状态失败而并发地被添加到LinkedList时,LinkedList将难以保证Node的正确添加,最终的结果可能是节点的数量有偏差,而且顺序也是混乱的。

在enq(final Node node)方法中，同步器通过“死循环”来保证节点的正确添加，在“死循环”中只有通过CAs将节点设置成为尾节点之后，当前线程扌能从该方法返回,否则，当前线程不断地尝试设置。可以看出,enq(final Node node)方法将并发添加节点的请求通过CAS变得“串行化”了。

节点进入同步队列之后，就进入了一个自旋的过程,每个节点(或者说每个线程)都在自省地观察，当条件满足,获取到了同步状态，就可以从这个自旋过程中退出，否则依旧留在这个自旋过程中(并会阻塞节点的线程)，如代码清单5-5所示。

在acquireQueued(final Node node,int arg)方法中，当前线程在“死循环””中尝试获取同步状态，而只有前驱节点是头节点才能够尝试获取同步状态，这是为什么?原因有两个，如下。

• 第一，头节点是成功获取到同步状态的节点,而头节点的线程释放了同步状态之后，将会唤醒其后继节点，后继节点的线程被唤醒后需要检查自己的前驱节点是否是头节点。
• 第二，维护同步队列的FIFo原则。该方法中，节点自旋获取同步状态的行为如图5-4所示。

在图5-4中，由于非首节点线程前驱节点出队或者被中断而从等待状态返回,随后检查自己的前驱是否是头节点，如果是则尝试获取同步状态。可以看到节点和节点之间在循环检查的过程中基本不相互通信,而是简单地判断自己的前驱是否为头节点，这样就使得节点的释放规则符合FIFO，并且也便于对过早通知的处理(过早通知是指前驱节点不是头节点的线程由于中断而被唤醒)。

独占式同步状态获取流程,也就是acquire(int arg)方法调用流程,如图5-5所示。

当前线程获取同步状态并执行了相应逻辑之后,就需要释放同步状态，使得后续节点能够继续获取同步状态。通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会唤醒其后继节点(进而使后继节点重新尝试获取同步状态)。该方法代码如代码清单5-6所示。

该方法执行时，会唤醒头节点的后继节点线程, unparkSuccessor(Node node)方法使用LockSupport(在后面的章节会专门介绍)来唤醒处于等待状态的线程。

分析了独占式同步状态获取和释放过程后，适当做个总结：

• 在获取同步状态时,同步器维护一个同步队列,获取状态失败的线程都会被加入到队列中并在队列中进行自旋;
• 移出队列(或停止自旋)的条件是前驱节点为头节点且成功获取了同步状态。
• 在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

3.共享式同步状态获取与释放

共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。以文件的读写为例，如果一个程序在对文件进行读操作，那么这一时刻对于该文件的写操作均被阻塞,而读操作能够同时进行。写操作要求对资源的独占式访问,而读操作可以是共享式访问，两种不同的访问模式在同一时刻对文件或资源的访问情况，如图5-6所示。

在图5-6中，左半部分，共享式访问资源时，其他共享式的访问均被允许,而独占式访问被阻塞,右半部分是独占式访问资源时，同一时刻其他访问均被阻塞。

在acquireShared(int arg)方法中,同步器调用tryAcquireShared(int arg)方法尝试获取同步状态，tryAcquireShared(int arg)方法返回值为int类型,当返回值大于等于o时,表示能够获取到同步状态。因此,在共享式获取的自旋过程中,成功获取到同步状态并退出自旋的条件就是tryAcqutireShared(int arg)方法返回值大于等于0。可以看到,在doAcquireShared(int arg)方法的自旋过程中,如果当前节点的前驱为头节点时，尝试获取同步状态，如果返回值大于等于0，表示该次获取同步状态成功并从自旋过程中退出。

该方法在释放同步状态之后，将会唤醒后续处于等待状态的节点。对于能够支持多个线程同时访问的并发组件(比如Semaphore)，它和独占式主要区别在于tryReleaseShared(int arg)方法必须确保同步状态(或者资源数)线程安全释放,一般是通过循环和CAS来保证的,因为释放同步状态的操作会同时来自多个线程。

4.独占式超时获取同步状态

通过调用同步器的doAcquireNanos(int arg.long nanosTimeout)方法可以超时获取同步状态，即在指定的时间段内获取同步状态，如果获取到同步状态则返回true，否则,返回false。该方法提供了传统Java同步操作(比如synchronized关键字)所不具备的特性。

在分析该方法的实现前，先介绍一下响应中断的同步状态获取过程。在Java 5之前，当一个线程获取不到锁而被阻塞在synchronized之外时,对该线程进行中断操作，此时该线程的中断标志位会被修改,但线程依旧会阻塞在synchronized上，等待着获取锁。在Java 5中，同步器提供了acquireInterruptibly(int arg)方法，这个方法在等待获取同步状态时，如果当前线程被中断,会立刻返回，并抛出InterruptedException。

超时获取同步状态过程可以被视作响应中断获取同步状态过程的“增强版”，
doAcquireNanos(int arg,.long nanosTimeout)方法在支持响应中断的基础上,增加了超时获取的特性。针对超时获取，主要需要计算出需要睡眠的时间间隔nanosTimeout，为了防止过早通知,nanosTimeout计算公式为:nanosTimeout-=now-lastTime，其中now为当前唤醒时间, lastTime为上次唤醒时间,如果nanosTimeout大于0则表示超时时间未到,需要继续睡眠nanosTimeout纳秒，反之,表示已经超时。

该方法在自旋过程中，当节点的前驱节点为头节点时尝试获取同步状态，如果获取成功则从该方法返回,这个过程和独占式同步获取的过程类似,但是在同步状态获取失败的处理上有所不同。如果当前线程获取同步状态失败,则判断是否超时(nanosTimeout小于等于o表示已经超时)，如果没有超时，重新计算超时间隔nanosTimeout，然后使当前线程等待
nanosTimeout纳秒(当已到设置的超时时间，该线程会从LockSupport.parkNanos(Objectblocker,1ong nanos)方法返回)。

从图5-7中可以看出,独占式超时获取同步状态doAcquireNanos(int arg,long nanosTimeout)和独占式获取同步状态acquire(int args)在流程上非常相似，其主要区别在于未获取到同步状态时的处理逻辑。acquire(int args)在未获取到同步状态时，将会使当前线程一直处于等待状态，而doAcquireNanos(int arg,long nanosTimeout)会使当前线程等待nanosTimeout纳秒,如果当前线程在nanosTimeout纳秒内没有获取到同步状态，将会从等待逻辑中自动返回。

重入锁（ReentrantLock）

重入锁ReentrantLock，顾名思义,就是支持重进入的锁,它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。

可重入锁的作用

就是为了避免死锁，java中Synchronized和ReentrantLock都是可重入锁

重入锁的实现原理

通过为每个锁关联一个请求计数器（同步状态值）和一个获得该锁的线程。当计数器为0时，认为锁是未被占用的。线程请求一个未被占用的锁时，JVM将记录该线程并将请求计数器设置为1，此时该线程就获得了锁，当该线程再次请求这个锁，计数器将递增，当线程退出同步方法或者同步代码块时，计数器将递减，当计数器为0时，线程就释放了该对象，其他线程才能获取该锁。

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之, 是不公平的。公平的获取锁,也就是等待时间最长的线程最优先获取锁,也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。

事实上，公平的锁机制往往没有非公平的效率高，但是，并不是任何场景都是以TPS作为唯一的指标,公平锁能够减少“饥饿”发生的概率, 等待越久的请求越是能够得到优先满足。

1.实现重进入

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞,该特性的实现需要解决以下两个问题。

1)线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程,如果是,则再次成功获取。

2)锁的最终释放。线程重复n次获取了锁,随后在第n次释放该锁后,其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增,计数表示当前锁被重复获取的次数,而锁被释放时,计数自减,当计数等于o时表示锁已经成功释放。

成功获取锁的线程再次获取锁,只是增加了同步状态值,这也就要求ReentrantLock在释放同步状态时减少同步状态值。

如果该锁被获取了n次，那么前(n-1)次tryRelease(int releases)方法必须返回false，而只有同步状态完全释放了，才能返回true。可以看到,该方法将同步状态是否为0作为最终释放的条件，当同步状态为0时,将占有线程设置为nul1，并返回true，表示释放成功。

2.公平与非公平获取锁的区别

公平性与否是针对获取锁而言的,如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。

• 对于非公平锁,只要CAS设置同步状态成功,则表示当前线程获取了锁；
• 而公平锁则不同：加入了同步队列中当前节点是否有前驱节点的判断。如果有线程比当前线程更早地请求获取锁,需要等待前驱线程获取并释放锁之后才能继续获取锁。

• 公平性锁保证了锁的获取按照FIFO原则,而代价是进行大量的线程切换。
• 非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换,保证了其更大的吞吐量（支持刚释放锁的上一个线程重进入）。

读写锁

• 之前提到锁(如Mutex和ReentrantLock)基本都是排他锁,这些锁在同一时刻只允许一个线程进行访问；
• 而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时,所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁,通过分离读锁和写锁,使得并发性相比一般的排他锁有了很大提升。
• 除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构，它大部分时间提供读服务(例如查询和搜索)，而写操作占有的时间很少,但是写操作完成之后的更新需要对后续的读服务可见。
• 在没有读写锁支持的(Java 5之前)时候,如果需要完成上述工作就要使用Java的等待通知机制,就是当写操作开始时,所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后,所有等待的读操作扌能继续执行(写操作之间依靠synclronized关键进行同步)，这样做的目的是使读操作能读取到正确的数据,不会出现脏读。改用读写锁实现上述功能,只需要在读操作时获取读锁,写操作时获取写锁即可。当写锁被获取到时,后续(非当前写操作线程)的读写操作都会被阻塞,写锁释放之后,所有操作继续执行,编程方式相对于使用等待通知机制的实现方式而言,变得简单明了。

一般情况下，读写锁的性能都会比排它锁好,因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是ReentrantReadWriteLock（可重入读写锁）,它提供的特性如下。

ReentrantReadWriteLock特性

• 公平性选择
  • 支持非公平（默认）和公平的锁获取方式，吞吐量：非公平优于公平
• 支持重进入
  • 以读写线程为例:读线程在获取了读锁之后，能够再次获取读锁。而写线程
    重进入在获取了写锁之后能够再次获取写锁，同时也可以获取读锁
• 锁降级
  • 遵循获取写锁、获取读锁再释放写锁的次序，写锁能够降级成为读锁

读写锁ReentrantReadWriteLock的接口与示例

读写锁的实现分析

1.读写状态的设计

读写锁同样依赖自定义同步器来实现同步功能,而读写状态就是其同步器的同步状态。回想ReentrantLock中自定义同步器的实现,同步状态表示锁被一个线程重复获取的次数,而读写锁的自定义同步器需要在同步状态(一个整型变量)上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。

如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量,读写锁将变量切分成了两个部分,高16位表示读,低16位表示写，划分方式如图5-8所示。

当前同步状态表示一个线程已经获取了写锁,且重进人了两次，同时也连续获取了两次读锁。读写锁是如何迅速确定读和写各自的状态呢?答案是通过位运算。假设当前同步状态值为S，写状态等于S&Ox0000FFFF(将高16位全部抹去),读状态等于S>>>16(无符号补o右移16位)。当写状态增加1时，等于S+1，当读状态增加1时，等于S+(1<< 16)，也就是
S+0x00010000。

根据状态的划分能得出一个推论:S不等于0时，当写状态(S&0x0000FFFF)等于O时，则读状态(S>>>16)大于0，即读锁已被获取。

2.写锁的获取与释放

写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁,则增加写状态。如果当前线程在获取写锁时,读锁已经被获取(读状态不为0)或者该线程不是已经获取写锁的线程,则当前线程进入等待状态，获取写锁的代码如代码清单5-17所示。

该方法除了重入条件(当前线程为获取了写锁的线程)之外,增加了一个读锁是否存在的判断。如果存在读锁,则写锁不能被获取,原因在于:读写锁要确保写锁的操作对读锁可见，如果允许读锁在已被获取的情况下对写锁的获取，那么正在运行的其他读线程就无法感知到当前写线程的操作。因此,只有等待其他读线程都释放了读锁,写锁才能被当前线程获取,而写锁一旦被获取,则其他读写线程的后续访问均被阻塞。

写锁的释放与ReentrantLock的释放过程基本类似,每次释放均减少写状态，当写状态为0时表示写锁已被释放,从而等待的读写线程能够继续访问读写锁,同时前次写线程的修改对后续读写线程可见。

3.读锁的获取与释放

读锁是一个支持重进入的共享锁，它能够被多个线程同时获取,在没有其他写线程访问(或者写状态为0)时，读锁总会被成功地获取,而所做的也只是(线程安全的)增加读状态。如果当前线程已经获取了读锁,则增加读状态。如果当前线程在获取读锁时,写锁已被其他线程获取,则进入等待状态。获取读锁的实现从Java 5到Java 6变得复杂许多，主要原因是新增了一些功能.例如getReadHoldCount()方法,作用是返回当前线程获取读锁的次数。读状态是所有线程获取读锁次数的总和,而每个线程各自获取读锁的次数只能选择保存在ThreadLocal中，由线程自身维护,这使获取读锁的实现变得复杂。

在tryAcquireShared(int unused)方法中，如果其他线程已经获取了写锁,则当前线程获取读锁失败,进入等待状态。如果当前线程获取了写锁或者写锁未被获取,则当前线程(线程安全，依靠CAS保证)增加读状态,成功获取读锁。

读锁的每次释放(线程安全的,可能有多个读线程同时释放读锁)均减少读状态，减少的值是(1<< 16)。

4.锁降级

锁降级指的是写锁降级成为读锁。锁降级是指把持住(当前拥有的)写锁,再获取到读锁,随后释放(先前拥有的)写锁的过程。

接下来看一个锁降级的示例。因为数据不常变化,所以多个线程可以并发地进行数据处理，当数据变更后，如果当前线程感知到数据变化,则进行数据的准备工作,同时其他处理线程被阻塞,直到当前线程完成数据的准备工作，如代码清单5-19所示。

上述示例中，当数据发生变更后,update变量(布尔类型且volatile修饰)被设置为false,此时所有访问processData()方法的线程都能够感知到变化,但只有一个线程能够获取到写锁,其他线程会被阻塞在读锁和写锁的lock()方法上。当前线程获取写锁完成数据准备之后，再获取读锁,随后释放写锁,完成锁降级。

• 锁降级中读锁的获取是否必要呢?
  • 答案是必要的。主要是为了保证数据的可见性,如果当前线程不获取读锁而是直接释放写锁,假设此刻另一个线程(记作线程T)获取了写锁并修改了数据,那么当前线程无法感知线程T的数据更新：如果当前线程获取读锁,即遵循锁降级的步骤,则线程T将会被阻塞,直到当前线程使用数据并释放读锁之后,线程T才能获取写锁进行数据更新。
• RentrantReadWriteLock不支持锁升级(把持读锁、获取写锁,最后释放读锁的过程)。目的也是保证数据可见性,如果读锁已被多个线程获取，其中任意线程成功获取了写锁并更新了数据,则其更新对其他获取到读锁的线程是不可见的。

LockSupport工具

当需要阻塞或唤醒一个线程的时候，都会使用LockSupport工具类来完成相应工作。LockSupport定义了一组的公共静态方法,这些方法提供了最基本的线程阻塞和唤醒功能，而LockSupport也成为构建同步组件的基础工具。

LockSupport定义了一组以park开头的方法用来阻塞当前线程,以及unpark(Thread thread)方法来唤醒一个被阻塞的线程。Park有停车的意思，假设线程为车辆,那么park方法代表着停车，而unpark方法则是指车辆后动离开，这些方法以及描述如表5-10所示。

在Java 6中,LockSupport增加了park(Object blocker)、 parkNanos(Object blocker,long nanos)和parkUntil(Object blocker,long deadline)3个方法,用于实现阻塞当前线程的功能,其中参数blocker是用来标识当前线程在等待的对象(以下称为阻塞对象)，该对象主要用于问题排查和系统监控。

Condition接口

任意一个Java对象,都拥有一组监视器方法(定义在java.lang.Object上)，主要包括wait()、wait(long timeout)、 notify()以及notifyAll()方法,这些方法与synchronized同步关键字配合，可以实现等待/通知模式。Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式,但是这两者在使用方式以及功能特性上还是有差别的。

通过对比Object的监视器方法和Condition接口，可以更详细地了解Condition的特性,对比项与结果如表5-12所示。

Condition接口与示例

Condition定义了等待/通知两种类型的方法,当前线程调用这些方法时,需要提前获取到Condition对象关联的锁。Condition对象是由Lock对象(调用Lock对象的newCondition()方法)创建出来的,换句话说，Condition是依赖Lock对象的。

Condition的使用方式比较简单,需要注意在调用方法前获取锁。

一般都会将Condition对象作为成员变量。当调用await()方法后，当前线程会释放锁并在此等待,而其他线程调用Condition对象的signal()方法,通知当前线程后，当前线程从await()方法返回，并且在返回前已经获取了锁。

Condition定义的(部分)方法以及描述如表5-13所示。

获取一个Condition必须通过Lock的newCondition()方法。下面通过一个有界队列的示例来深入了解Condition的使用方式。有界队列是一种特殊的队列，当队列为空时,队列的获取操作将会阻塞获取线程，直到队列中有新增元素,当队列已满时,队列的插入操作将会阻塞插入线程，直到队列出现“空位”，如代码清单5-21所示。

生产者-消费者模式

首先需要获得锁,目的是确保数组修改的可见性和排他性。当数组数量等于数组长度时，表示数组已满,则调用notFull.await()，当前线程随之释放锁并进入等待状态。如果数组数量不等于数组长度，表示数组未满,则添加元素到数组中，同时通知等待在notEnpty上的线程,数组中已经有新元素可以获取。

在添加和删除方法中使用while循环而非if判断,目的是防止过早或意外的通知，只有条件符合才能够退出循环。回想之前提到的等待/通知的经典范式,二者是非常类似的。

Condition的实现分析

ConditionObject是同步器AbstractQueuedSynchronizer的内部类, 因为Condition的操作需要获取相关联的锁,所以作为同步器的内部类也较为合理。每个Condition对象都包含着一个队列(以下称为等待队列)，该队列是Condition对象实现等待/通知功能的关键。

1.等待队列

等待队列是一个FIFO的队列,在队列中的每个节点都包含了一个线程引用，该线程就是在Condition对象上等待的线程,如果一个线程调用了Condition.await()方法,那么该线程将会释放锁、构造成节点加入等待队列并进入等待状态。事实上,节点的定义复用了同步器中节点的定义，也就是说,同步队列和等待队列中节点类型都是同步器的静态内部类
AbstractQueuedSynchronizer.Node。

一个Condition包含一个等待队列,Condition拥有首节点(firstWaiter)和尾节点
(lastWaiter)。当前线程调用Condition.await()方法,将会以当前线程构造节点,并将节点从尾部加人等待队列，等待队列的基本结构如图5-9所示。

如图所示,Condition拥有首尾节点的引用,而新增节点只需要将原有的尾节点nextWaiter指向它，并且更新尾节点即可。上述节点引用更新的过程并没有使用CAS保证,原因在于调用await()方法的线程必定是获取了锁的线程，也就是说该过程是由锁来保证线程安全的。

在Object的监视器模型上，一个对象拥有一个同步队列和等待队列, 而并发包中的Lock(更确切地说是同步器)拥有一个同步队列和多个等待队列,其对应关系如图5-10所示。

如图所示,Condition的实现是同步器的内部类，因此每个Condition实例都能够访问同步器提供的方法,相当于每个Condition都拥有所属同步器的引用。

2.等待

调用Condition的await()方法(或者以await开头的方法)，会使当前线程进入等待队列并释放锁,同时线程状态变为等待状态。当从await()方法返回时,当前线程一定获取了Condition相关联的锁。
如果从队列(同步队列和等待队列)的角度看await()方法,当调用await()方法时，相当于同步队列的首节点(获取了锁的节点)移动到Condition的等待队列中。

Condition的await()方法，如代码清单5-22所示。

调用该方法的线程成功获取了锁的线程，也就是同步队列中的首节点，该方法会将当前线程构造成节点并加入等待队列中，然后释放同步状态,唤醒同步队列中的后继节点，然后当前线程会进入等待状态。

当等待队列中的节点被唤醒,则唤醒节点的线程开始尝试获取同步状态。如果不是通过其他线程调用Condition.signal()方法唤醒,而是对等待线程进行中断,则会抛出
InterruptedException。

如图所示,同步队列的首节点并不会直接加入等待队列,而是通过addConditionWaiter()方
法把当前线程构造成一个新的节点并将其加入等待队列中。

3.通知

调用Condition的signal()方法.将会唤醒在等待队列中等待时间最长的节点(首节点)，在唤醒节点之前,会将节点移到同步队列中。

Condition的signal()方法，如代码清单5-23所示。

调用该方法的前置条件是当前线程必须获取了锁,可以看到signal()方法进行了
isHeldExclusively)检查，也就是当前线程必须是获取了锁的线程。接着获取等待队列的首节点，将其移动到同步队列并使用LockSupport唤醒节点中的线程。

节点从等待队列移动到同步队列的过程如图5-12所示。

通知过程：

• 先移动到同步队列，再唤醒。通过调用同步器的enq(Node node)方法,等待队列中的头节点线程安全地移动到同步队列。当节点移动到同步队列后，当前线程再使用LockSupport唤醒该节点的线程。
• 被唤醒后的线程,将从await()方法中的while循环中退出(isOnSyncQueue(Node node)方法返回true,节点已经在同步队列中)，进而调用同步器的acquireQueued()方法加入到获取同步状态的竞争中。
• 成功获取同步状态(或者说锁)之后，被唤醒的线程将从先前调用的await()方法返回,此时该线程已经成功地获取了锁，可以执行后续操作。

Condition的signalAll()方法,相当于对等待队列中的每个节点均执行一次signal()方法,效果就是将等待队列中所有节点全部移动到同步队列中,并唤醒每个节点的线程。