每一个 Java 的高级程序员在体验过多线程程序开发之后，都需要问自己一个问题，Java 内置的锁是如何实现的?最常用的最简单的锁要数 ReentrantLock，使用它加锁时如果没有立即加成功，就会阻塞当前的线程等待其它线程释放锁之后再重新尝试加锁，那线程是如何实现阻塞自己的?

其它线程释放锁之后又是如果唤醒当前线程的?当前线程是如何得出自己没有加锁成功这一结论的? 陕西优就业小编今天给大家分享的这篇内容将会从根源上回答上面提到的所有问题。

1、线程阻塞原语

Java 的线程阻塞和唤醒是通过 Unsafe 类的 park 和 unpark 方法做到的。

这两个方法都是 native 方法，它们本身是由 C 语言来实现的核心功能。park 的意思是停车，让当前运行的线程 Thread.currentThread() 休眠，unpark 的意思是解除停车，唤醒指定线程。

这两个方法在底层是使用操作系统提供的信号量机制来实现的。具体实现过程要深究 C 代码，这里暂时不去具体分析。park 方法的两个参数用来控制休眠多长时间，第一个参数 isAbsolute 表示第二个参数是绝对时间还是相对时间，单位是毫秒。

线程从启动开始就会一直跑，除了操作系统的任务调度策略外，它只有在调用 park 的时候才会暂停运行。锁可以暂停线程的奥秘所在正是因为锁在底层调用了 park 方法。

2、parkBlocker

线程对象 Thread 里面有一个重要的属性 parkBlocker，它保存当前线程因为什么而 park。就好比停车场上停了很多车，这些车主都是来参加一场拍卖会的，等拍下自己想要的物品后，就把车开走。那么这里的 parkBlocker 大约就是指这场「拍卖会」。它是一系列冲突线程的管理者协调者，哪个线程该休眠该唤醒都是由它来控制的。

当线程被 unpark 唤醒后，这个属性会被置为 null。Unsafe.park 和 unpark 并不会帮我们设置 parkBlocker 属性，负责管理这个属性的工具类是 LockSupport，它对 Unsafe 这两个方法进行了简单的包装。

Java 的锁数据结构正是通过调用 LockSupport 来实现休眠与唤醒的。线程对象里面的 parkBlocker 字段的值就是下面我们要讲的「排队管理器」。

3、排队管理器

当多个线程争用同一把锁时，必须有排队机制将那些没能拿到锁的线程串在一起。当锁释放时，锁管理器就会挑选一个合适的线程来占有这个刚刚释放的锁。

每一把锁内部都会有这样一个队列管理器，管理器里面会维护一个等待的线程队列。ReentrantLock 里面的队列管理器是 AbstractQueuedSynchronizer，它内部的等待队列是一个双向列表结构。

加锁不成功时，当前的线程就会把自己纳入到等待链表的尾部，然后调用 LockSupport.park 将自己休眠。其它线程解锁时，会从链表的表头取一个节点，调用 LockSupport.unpark 唤醒它。

AbstractQueuedSynchronizer 类是一个抽象类，它是所有的锁队列管理器的父类，JDK 中的各种形式的锁其内部的队列管理器都继承了这个类，它是 Java 并发世界的核心基石。

比如 ReentrantLock、ReadWriteLock、CountDownLatch、Semaphore、ThreadPoolExecutor 内部的队列管理器都是它的子类。这个抽象类暴露了一些抽象方法，每一种锁都需要对这个管理器进行定制。而 JDK 内置的所有并发数据结构都是在这些锁的保护下完成的，它是JDK 多线程高楼大厦的地基。

锁管理器维护的只是一个普通的双向列表形式的队列，这个数据结构很简单，但是仔细维护起来却相当复杂，因为它需要精细考虑多线程并发问题，每一行代码都写的无比小心。

JDK 锁管理器的实现者是 Douglas S. Lea，Java 并发包几乎全是他单枪匹马写出来的，在算法的世界里越是精巧的东西越是适合一个人来做。

后面我们将 AbstractQueuedSynchronizer 简写成 AQS。我必须提醒各位读者，AQS 太复杂了，如果在理解它的路上遇到了挫折，这很正常。目前市场上并不存在一本可以轻松理解 AQS 的书籍，能够吃透 AQS 的人太少太少，我自己也不算。

4、公平锁与非公平锁

公平锁会确保请求锁和获得锁的顺序，如果在某个点锁正处于自由状态，这时有一个线程要尝试加锁，公平锁还必须查看当前有没有其它线程排在排队，而非公平锁可以直接插队。联想一下在肯德基买汉堡时的排队场景。

也许你会问，如果某个锁处于自由状态，那它怎么会有排队的线程呢?我们假设此刻持有锁的线程刚刚释放了锁，它唤醒了等待队列中第一个节点线程，这时候被唤醒的线程刚刚从 park 方法返回，接下来它就会尝试去加锁，那么从 park 返回到加锁之间的状态就是锁的自由态，这很短暂，而这短暂的时间内还可能有其它线程也在尝试加锁。

其次还有一点需要注意，执行了 Lock.park 方法的线程自我休眠后，并不是非要等到其它线程 unpark 了自己才会醒来，它可能随时会以某种未知的原因醒来。我们看源码注释，park 返回的原因有四种：

①其它线程 unpark 了当前线程;

②时间到了自然醒(park 有时间参数);

③其它线程 interrupt 了当前线程;

④其它未知原因导致的「假醒」;

文档中没有明确说明何种未知原因会导致假醒，它倒是说明了当 park 方法返回时并不意味着锁自由了，醒过来的线程在重新尝试获取锁失败后将会再次 park 自己。所以加锁的过程需要写在一个循环里，在成功拿到锁之前可能会进行多次尝试。

计算机世界非公平锁的服务效率要高于公平锁，所以 Java 默认的锁都使用了非公平锁。不过现实世界似乎非公平锁的效率会差一点，比如在肯德基如果可以不停插队，你可以想象现场肯定一片混乱。为什么计算机世界和现实世界会有差异，大概是因为在计算机世界里某个线程插队并不会导致其它线程抱怨。

5、共享锁与排他锁

ReentrantLock 的锁是排他锁，一个线程持有，其它线程都必须等待。而 ReadWriteLock 里面的读锁不是排他锁，它允许多线程同时持有读锁，这是共享锁。共享锁和排他锁是通过 Node 类里面的 nextWaiter 字段区分的。

那为什么这个字段没有命名成 mode 或者 type 或者干脆直接叫 shared?这是因为 nextWaiter 在其它场景还有不一样的用途，它就像 C 语言联合类型的字段一样随机应变，只不过 Java 语言没有联合类型。

6、条件变量

关于条件变量，需要提出的第一个问题是为什么需要条件变量，只有锁还不够么?考虑下面的伪代码，当某个条件满足时，才去干某件事

当条件不满足时，就循环重试(其它线程会通过加锁来修改条件)，但是需要间隔 sleep，不然 CPU 就会因为空转而飙高。这里存在一个问题，那就是 sleep 多久不好控制。间隔太久，会拖慢整体效率，甚至会错过时机(条件瞬间满足了又立即被重置了)，间隔太短，又回导致 CPU 空转。有了条件变量，这个问题就可以解决了

await() 方法会一直阻塞在 cond 条件变量上直到被另外一个线程调用了 cond.signal() 或者 cond.signalAll() 方法后才会返回，await() 阻塞时会自动释放当前线程持有的锁，await() 被唤醒后会再次尝试持有锁(可能又需要排队)，拿到锁成功之后 await() 方法才能成功返回。

阻塞在条件变量上的线程可以有多个，这些阻塞线程会被串联成一个条件等待队列。当 signalAll() 被调用时，会唤醒所有的阻塞线程，让所有的阻塞线程重新开始争抢锁。如果调用的是 signal() 只会唤醒队列头部的线程，这样可以避免「惊群问题」。

await() 方法必须立即释放锁，否则临界区状态就不能被其它线程修改，condition_is_true() 返回的结果也就不会改变。 这也是为什么条件变量必须由锁对象来创建，条件变量需要持有锁对象的引用这样才可以释放锁以及被 signal 唤醒后重新加锁。

创建条件变量的锁必须是排他锁，如果是共享锁被 await() 方法释放了并不能保证临界区的状态可以被其它线程来修改，可以修改临界区状态的只能是排他锁。

有了条件变量，sleep 不好控制的问题就解决了。当条件满足时，调用 signal() 或者 signalAll() 方法，阻塞的线程可以立即被唤醒，几乎没有任何延迟。

7、条件等待队列

当多个线程 await() 在同一个条件变量上时，会形成一个条件等待队列。同一个锁可以创建多个条件变量，就会存在多个条件等待队列。这个队列和 AQS 的队列结构很接近，只不过它不是双向队列，而是单向队列。队列中的节点和 AQS 等待队列的节点是同一个类，但是节点指针不是 prev 和 next，而是 nextWaiter。

ConditionObject 是 AQS 的内部类，这个对象里会有一个隐藏的指针 this$0 指向外部的 AQS 对象，ConditionObject 可以直接访问 AQS 对象的所有属性和方法(加锁解锁)。位于条件等待队列里的所有节点的 waitStatus 状态都被标记为 CONDITION，表示节点是因为条件变量而等待。

8、队列转移

当条件变量的 signal() 方法被调用时，条件等待队列的头节点线程会被唤醒，该节点从条件等待队列中被摘走，然后被转移到 AQS 的等待队列中，准备排队尝试重新获取锁。这时节点的状态从 CONDITION 转为 SIGNAL，表示当前节点是被条件变量唤醒转移过来的。

被转移的节点的 nextWaiter 字段的含义也发生了变更，在条件队列里它是下一个节点的指针，在 AQS 等待队列里它是共享锁还是互斥锁的标志。

9、读写锁

读写锁分为两个锁对象 ReadLock 和 WriteLock，这两个锁对象共享同一个 AQS。AQS 的锁计数变量 state 将分为两个部分，前 16bit 为共享锁 ReadLock 计数，后 16bit 为互斥锁 WriteLock 计数。互斥锁记录的是当前写锁重入的次数，共享锁记录的是所有当前持有共享读锁的线程重入总次数。

读写锁同样也需要考虑公平锁和非公平锁。共享锁和互斥锁的公平锁策略和 ReentrantLock 一样，就是看看当前还有没有其它线程在排队，自己会乖乖排到队尾。非公平锁策略不一样，它会比较偏向于给写锁提供更多的机会。

如果当前 AQS 队列里有任何读写请求的线程在排队，那么写锁可以直接去争抢，但是如果队头是写锁请求，那么读锁需要将机会让给写锁，去队尾排队。 毕竟读写锁适合读多写少的场合，对于偶尔出现一个写锁请求就应该得到更高的优先级去处理。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69902581/viewspace-2666640/，如需转载，请注明出处，否则将追究法律责任。