一些关键词语以及常用术语，主要如下：

• 信号量(Semaphore): 是在多线程环境下使用的一种设施，是可以用来保证两个或多个关键代码段不被并发调用，也是作系统用来解决并发中的互斥和同步问题的一种方法。
• 信号量机制(Semaphores)： 用来解决同步/互斥的问题的，它是1965年,荷兰学者 Dijkstra提出了一种卓有成效的实现进程互斥与同步的方法。 - 管程(Monitor) : 一般是指管理共享变量以及对共享变量的操作过程，让它们支持并发的一种机制。

基本概述

在Java领域中，我们可以将锁大致分为基于Java语法层面(关键词)实现的锁和基于JDK层面实现的锁。

在Java领域中, 尤其是在并发编程领域，对于多线程并发执行一直有两大核心问题：同步和互斥。其中：

• 互斥(Mutual Exclusion)：一个公共资源同一时刻只能被一个进程或线程使用，多个进程或线程不能同时使用公共资源。即就是同一时刻只允许一个线程访问共享资源的问题。
• 同步(Synchronization)：两个或两个以上的进程或线程在运行过程中协同步调，按预定的先后次序运行。即就是线程之间如何通信、协作的问题。

虽然，Java在基于语法层面(synchronized 关键字)实现了对管程技术,但是从使用方式和性能上来说，内置锁(synchronized 关键字)的粒度相对过大，不支持超时和中断等问题。
为了弥补这些问题，从JDK层面对其“重复造轮子”，在JDK内部对其重新设计和定义，甚至实现了新的特性。
在Java领域中，从JDK源码分析来看，基于JDK层面实现的锁大致主要可以分为以下4种方式：

• 基于Lock接口实现的锁
• 基于ReadWriteLock接口实现的锁
• 基于AQS基础同步器实现的锁
• 基于自定义API操作实现的锁

从阅读源码不难发现，在Java SDK 并发包主要通过AbstractQueuedSynchronizer(AQS)实现多线程同步机制的封装与定义，而通过Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。
在JDK源码中，同步器位于java.util.concurrent.locks包下，其基本定义是AbstractQueuedSynchronizer类，即就是我们常说的AQS同步器。

1. 设计思想

一个标准的AQS同步器主要有同步状态机制，等待队列，条件队列，独占模式，共享模式等五大核心要素组成。

JDK的JUC(java.util.concurrent.)包中提供了各种并发工具，但是大部分同步工具的实现基于AbstractQueuedSynchronizer类实现，其内部结构主要如下：

• 同步状态机制(Synchronization Status)：主要用于实现锁(Lock)机制，是指同步状态，其要求对于状态的更新必须原子性的
• 等待队列(Wait Queue)：主要用于存放等待线程获取到的锁资源，并且把线程维护到一个Node(节点)里面和维护一个非阻塞的CHL Node FIFO(先进先出)队列，主要是采用自旋锁+CAS操作来保证节点插入和移除的原子性操作。
• 条件队列(Condition Queue)：用于实现锁的条件机制，一般主要是指替换“等待-通知”工作机制，主要是通过ConditionObject对象实现Condition接口提供的方法实现。
• 独占模式(Exclusive Mode)：主要用于实现独占锁，主要是基于静态内部类Node的常量标志EXCLUSIVE来标识该节点是独占模式
• 共享模式(Shared Mode)：主要用于实现共享锁，主要是基于静态内部类Node的常量标志SHARED来标识该节点是共享模式

其中，对于AbstractQueuedSynchronizer类的实现原理，我们可以从如下几个方面来看：

public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {private static final long serialVersionUID = 7373984972572414691 L;protected AbstractQueuedSynchronizer() {}/*** 等待队列： head-头节点*/private transient volatile Node head;/*** 等待队列： tail-尾节点*/private transient volatile Node tail;/*** 同步状态：32位整数类型，更新同步状态(state)时必须保证其是原子性的*/private volatile int state;/*** 自旋锁消耗超时时间阀值(threshold)： threshold < 1000ns时，表示竞争时选择自旋；threshold > 1000ns时，表示竞争时选择系统阻塞*/static final long spinForTimeoutThreshold = 1000 L;/*** CAS原子性操作*/private static final Unsafe unsafe = Unsafe.getUnsafe();/*** stateOffset*/private static final long stateOffset;/*** headOffset*/private static final long headOffset;/*** tailOffset*/private static final long tailOffset;/*** waitStatusOffset*/private static final long waitStatusOffset;/*** nextOffset*/private static final long nextOffset;static {try {stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state"));headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus"));nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next"));} catch (Exception ex) {throw new Error(ex);}}private final boolean compareAndSetHead(Node update)  {return unsafe.compareAndSwapObject(this, headOffset, null, update);}private final boolean compareAndSetTail(Node expect, Node update) {return unsafe.compareAndSwapObject(this, tailOffset, expect, update);}private static final boolean compareAndSetWaitStatus(Node node,int expect,int update) {return unsafe.compareAndSwapInt(node, waitStatusOffset,expect, update);}private static final boolean compareAndSetNext(Node node,Node expect,Node update) {return unsafe.compareAndSwapObject(node, nextOffset, expect, update);}protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update);}}

[1]. AbstractQueuedSynchronizer类的实现原理是继承了基于AbstractOwnableSynchronizer类的抽象类，其中主要对AQS同步器的通用特性和方法进行抽象封装定义，主要包括如下方法：

public abstract class AbstractOwnableSynchronizer
implements java.io.Serializable {private static final long serialVersionUID = 3737899427754241961 L;protected AbstractOwnableSynchronizer() {}/***  同步器拥有者*/private transient Thread exclusiveOwnerThread;/*** 设置同步器拥有者：把线程当作参数传入，指定某个线程为独享*/protected final void setExclusiveOwnerThread(Thread thread) {exclusiveOwnerThread = thread;}/*** 获取同步器拥有者：获取指定的某个线程*/protected final Thread getExclusiveOwnerThread() {return exclusiveOwnerThread;}
}

• setExclusiveOwnerThread(Thread thread)方法： 把某个线程作为参数传入，从而设置AQS同步器的所有者，即就是我们设置的某个线程
• getExclusiveOwnerThread()方法： 获取当前AQS同步器的所有者，即就是我们指定的某个线程

[2]. 对于同步状态(state)，其类型是32位整数类型，并且是被volatile修饰的，表示在更新同步状态(state)时必须保证其是原子性的。
[3]. 对于等待队列的结构，主要是在Node定义了head和tail变量，其中head表示头部节点，tail表示尾部节点
[4].对于等待队列的结构提到的Node类来说，主要内容如下：

static final class Node {/** Marker to indicate a node is waiting in shared mode */static final Node SHARED = new Node();/** Marker to indicate a node is waiting in exclusive mode */static final Node EXCLUSIVE = null;/** waitStatus value to indicate thread has cancelled */static final int CANCELLED = 1;/** waitStatus value to indicate successor's thread needs unparking */static final int SIGNAL = -1;/** waitStatus value to indicate thread is waiting on condition */static final int CONDITION = -2;/*** waitStatus value to indicate the next acquireShared should* unconditionally propagate*/static final int PROPAGATE = -3;/*** Status field, taking on only the values:*   SIGNAL:     The successor of this node is (or will soon be)*               blocked (via park), so the current node must*               unpark its successor when it releases or*               cancels. To avoid races, acquire methods must*               first indicate they need a signal,*               then retry the atomic acquire, and then,*               on failure, block.*   CANCELLED:  This node is cancelled due to timeout or interrupt.*               Nodes never leave this state. In particular,*               a thread with cancelled node never again blocks.*   CONDITION:  This node is currently on a condition queue.*               It will not be used as a sync queue node*               until transferred, at which time the status*               will be set to 0. (Use of this value here has*               nothing to do with the other uses of the*               field, but simplifies mechanics.)*   PROPAGATE:  A releaseShared should be propagated to other*               nodes. This is set (for head node only) in*               doReleaseShared to ensure propagation*               continues, even if other operations have*               since intervened.*   0:          None of the above*** The field is initialized to 0 for normal sync nodes, and* CONDITION for condition nodes.  It is modified using CAS* (or when possible, unconditional volatile writes).*/volatile int waitStatus;/*** Link to predecessor node that current node/thread relies on*/volatile Node prev;/*** Link to the successor node that the current node/thread*/volatile Node next;/*** The thread that enqueued this node.  Initialized on* construction and nulled out after use.*/volatile Thread thread;/*** Link to next node waiting on condition, or the special*/Node nextWaiter;/*** Returns true if node is waiting in shared mode.*/final boolean isShared() {return nextWaiter == SHARED;}final Node predecessor() throws NullPointerException {Node p = prev;if (p == null)throw new NullPointerException();elsereturn p;}Node() { // Used to establish initial head or SHARED marker}Node(Thread thread, Node mode) { // Used by addWaiterthis.nextWaiter = mode;this.thread = thread;}Node(Thread thread, int waitStatus) { // Used by Conditionthis.waitStatus = waitStatus;this.thread = thread;}}

• 标记Node的工作模式常量标记：主要维护了SHARED和EXCLUSIVE等2个静态字面常量，其中 SHARED 用于标记Node中是共享模式，EXCLUSIVE:用于标记Node中是独享模式
• 标记等待状态的静态字面常量标记： 主要维护了0(表示无状态)，SIGNAL(-1,表示后续节点中的线程通过park进入等待，当前节点在释放和取消时，需要通过unpark解除后后续节点的等待)，CANCELLED(1,表示当前节点中的线程因为超时和中断被取消)，CONDITION(-2,表示当前节点在条件队列中)，PROPAGATE(-3,SHARED共享模式的头节点描述状态，表示无条件往下传播)等5个静态字面常量
• 维护了一个等待状态(waitStatus): 主要用于描述等待队列中节点的状态，其取值范围为0(waitStatus=0,表示无状态)，SIGNAL(waitStatus=-1,表示等待信号状态)，CANCELLED(waitStatus=1,表示取消状态)，CONDITION(waitStatus=-2,表示条件状态)，PROPAGATE(waitStatus=-3,表示SHARED共享模式状态)等5个静态字面常量，CAS操作时写入，默认值为0。
• 维护了Node的2个结构节点变量： 主要是prev和next，其中，prev表示前驱节点，next表示后续节点，表示构成双向向链表，构成了等待队列的数据结构
• 维护了一个状态工作模式标记： 主要是维护了一个nextWaiter，用于表示在等待队列中当前节点在是共享模式还是独享模式，而对于条件队列来说，用于组成单向链表结构
• 维护了一个线程对象变量： 主要用于记录当前节点中的线程thread

[5].对于自旋锁消耗超时时间阀值(spinForTimeoutThreshold),主要表示系统依据这个阀值来选择自旋方式还是系统阻塞。一般假设这个threshold，当 threshold < 1000ns时，表示竞争时选择自旋；否则，当threshold > 1000ns时，表示竞争时选择系统阻塞
[6].对于带有Offset 等变量对应各自的句柄，主要用于执行CAS操作。在JDK1.8版本之前，CAS操作主要通过Unsafe类来说实现；在JDK1.8版本之后，已经开始利用VarHandle来替代Unsafe类操作实现。
[7].对于CAS操作来说，主要提供了如下几个方法：

• compareAndSetState(int expect, int update)方法：CAS操作原子更新状态
• compareAndSetHead(Node update)方法：CAS操作原子更新头部节点
• compareAndSetTail(Node expect, Node update)方法：CAS操作原子更新尾部节点
• compareAndSetWaitStatus(Node node, int expect,int update)方法：CAS操作原子更新等待状态
• compareAndSetNext(Node node,Node expect,Node update)方法：CAS操作原子更新后续节点

[8].除此之外，还包括许多辅助的操作方法，具体可参考源码分析。

2. 基本实现

一个标准的AQS同步器最核心底层设计实现是一个非阻塞的CHL Node FIFO(先进先出)队列数据结构，通过采用自旋锁+CAS操作的方法来保证原子性操作。

总的来说，一个AQS基础同步器，底层的数据结构采用的是一个非阻塞的CHL Node FIFO(先进先出)队列数据结构，而实现的核心算法则是采用自旋锁+CAS操作的方法。
首先，对于非阻塞的CHL Node FIFO(先进先出)队列数据结构，一般来说，FIFO(First In First Out,先进先出)队列是一个有序列表，属于抽象型数据类型(Abstract Data Type,ADT),所有的插入和删除操作都发生在队首(Front)和队尾(Rear)两端，具有先进先出的特性。

/*** 等待队列： head-头节点*/private transient volatile Node head;/*** 等待队列： tail-尾节点*/private transient volatile Node tail;/*** Inserts node into queue, initializing if necessary. See picture above.* @param node the node to insert* @return node's predecessor*/private Node enq(final Node node) {for (;;) {Node t = tail;if (t == null) { // Must initializeif (compareAndSetHead(new Node()))tail = head;} else {node.prev = t;if (compareAndSetTail(t, node)) {t.next = node;return t;}}}}/*** Creates and enqueues node for current thread and given mode.** @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared* @return the new node*/private Node addWaiter(Node mode) {Node node = new Node(Thread.currentThread(), mode);// Try the fast path of enq; backup to full enq on failureNode pred = tail;if (pred != null) {node.prev = pred;if (compareAndSetTail(pred, node)) {pred.next = node;return node;}}enq(node);return node;}

在AQS同步器的源码中，主要是通过静态内部类Node来实现的这个非阻塞的CHL Node FIFO(先进先出)队列数据结构， 维护了两个变量head和tail，其中head对应队首(Front)，tail对应队尾(Rear)。同时，还定义了addWaiter(Node mode)方法来表示入队操作，其中有个enq(final Node node)方法，主要用于初始化队列中head和tail的设置。
其次，AQS同步器以CLH锁为基础，其中CLH锁是一种自旋锁，对于自旋锁的实现方式来看，主要可以分为普通自旋锁和自适应自旋锁，CLH锁和MCS锁等4种，其中：

• 普通自旋锁：多个线程不断自旋，不断尝试获取锁，其不具备公平性和由于要保证CPU和缓存以及主存之间的数据一致性，其开销较大。
• 自适应自旋锁：主要是为解决普通自旋锁的公平性问题，引入了一个排队机制，一般称为排他自旋锁，其具备公平性，但是没有解决保证CPU和缓存以及主存之间的数据一致性问题，其开销较大。
• CLH锁：通过一定手段将线程对于某一个共享变量的轮询竞争转化为一个线程队列，且队列中的线程各自轮询自己本地变量。
• MCS锁：主旨在于解决 CLH锁的问题，也是基于FIFO队列，与CLH锁不同是，只对本地变量自旋，前驱节点负责通知MCS锁中线程自适结束。

自旋锁是一种实现同步的方案，属于一种非阻塞锁，与常规锁主要的区别就在于获取锁失败之后的处理方式不同，主要体现在：

• 一般情况下，常规锁在获取锁失败之后，会将线程阻塞并适当时重新唤醒
• 而自旋锁则是使用自旋来替换阻塞操作，主要是线程会不断循环检查该锁是否被释放，一旦释放线程便会获取锁资源。

从本质上讲，自旋是一钟忙等待状态，会一直消耗CPU的执行时间。一般情况下，常规互斥锁适用于持有锁长时间的情况，自旋锁适合持有时间短的情况。
其中，对于CLH锁来说，其核心是为解决同步带来的花销问题，Craig，Landim，Hagersten三人发明了CLH锁，其中主要是：

• 构建一个FIFO(先进先出)队列，构建时主要通过移动尾部节点tail来实现队列的排队，每个想获得锁的线程都会创建一个新节点(next)并通过CAS操作原子操作将新节点赋予给tail，当前线程轮询前一个节点的状态。
• 执行完线程后，只需将当前线程对应节点状态设置为解锁即可，主要是判断当前节点是否为尾部节点，如果是直接设置尾部节点设置为空。由于下一个节点一直在轮询，所以可以获得锁。

CLH锁将众多线程长时间对资源的竞争，通过有序化这些线程将其转化为只需要对本地变量检测。唯一存在竞争的地方就是入队之前对尾部节点tail 的竞争，相对来说，当前线程对资源的竞争次数减少，这节省了CPU缓存同步的消耗，从而提升了系统性能。
但是同时也有一个问题，CLH锁虽然解决了大量线程同时操作同一个变量时带来的开销问题，如果前驱节点和当前节点在本地主存中不存在，则访问时间过长，也会引起性能问题。
为了让CLH锁更容易实现取消和超时的功能，AQS同步器在设计时进行了改造，主要体现在：节点的结构和节点等待机制。其中：

• 节点的结构： 主要引入了头节点和尾节点，分别指向队列头部和尾部，对于锁的相关操作都与其息息相关，并且每个节点都引入了前驱节点和后继节点。
• 节点等待机制： 主要在原来的自旋基础上增加了系统阻塞唤醒，主要体现在 自旋锁消耗超时时间阀值(threshold)： threshold < 1000ns时，表示竞争时选择自旋；threshold > 1000ns时，表示竞争时选择系统阻塞。

由此可见，主要是通过前驱节点和后继节点的引用连接起来形成一个链表队列，其中对于入队，检测节点，出队，判断超时，取消节点等操作主要如下：

• 入队(enqueue): 主要采用一个无限循环进行CAS操作，即就是使用自旋方式竞争直到成功。
• 检测节点(checkedPrev): 一般在入队完成后，主要是检测判断当前节点的前驱节点是否为头节点， 一般自旋方式是直接进入循环检测，而系统阻塞方式是当前线程先检测，其中如果是头节点并成功获取锁，则直接返回，当前线程不阻塞，否则对当前线程进行阻塞。
• 出队(dequeue):主要负责唤醒等待队列中的后继节点，并且按照条件往下传播有序执行
• 判断超时(checkedTimeout): 队列中等待锁的线程可能因为中断或者超时的情况，当总耗时大于等于自定义耗时就直接返回，即就是
• 取消节点(cancel): 主要是对于中断和超时而涉及到取消操作，而且这样的情况不再参与锁竞争，即就是一般通过调用compareAndSetNext(Node node, Node expect,Node update)来进行CAS操作。

最后，AQS同步器中使用了CAS操作，其中CAS(Compare And Swap,比较并交换)操作时一种乐观锁策略，主要涉及三个操作数据：内存值，预期值，新值，主要是指当且仅当预期值和内存值相等时才去修改内存值为新值。
一般来说，CAS操作的具体逻辑，主要可以分为三个步骤：

• 首先，检查某个内存值是否与该线程之前取到值一样。
• 其次，如果不一样，表示此内存值已经被别的线程修改，需要舍弃本次操作。
• 最后，如果时一样，表示期间没有线程更改过，则需要用新值执行更新内存值。

除此之外，需要注意的是CAS操作具有原子性，主要是由CPU硬件指令来保证，并且通过Java本地接口(Java Native Interface,JNI)调用本地硬件指令实现。

• 当然，CAS操作避免了悲观策略独占对象的 问题，同时提高了并发性能，但是也有以下三个问题：乐观策略只能保证一个共享变量的原子操作，如果是多个变量，CAS便不如互斥锁，主要是CAS操作的局限所致。
• 长时间循环操作可能导致开销过大。
• 经典的ABA问题： 主要是检查某个内存值是否与该线程之前取到值一样，这个判断逻辑不严谨。解决ABA问题的核心在于，引入版本号，每次更新变量值更新版本号。

而在AQS同步器中，为了保证并发实现保证原子性，而且是硬件级别的原子性，一般是通过JNI(Java native interface,Java 本地接口)方式让Java代码调用C/C++本地代码。
需要注意的是，在Java领域中，对于CAS操作实现，主要有亮点问题：

• JDK1.8版本之前，CAS操作主要使用Unsafe类来执行底层操作，一般并发和线程操作时，主要用compareAndSwapObject，compareAndSwapInt，compareAndSwapLong等来实现CAS，而对于线程调度主要是park和unpark方法，其主要在sun.misc包下面。
• JDK1.8版本之后，JDK1.9的CAS操作主要使用VarHandle类，只是用VarHandle替代了一部分Unsafe类的操作，但是对于新版本中Unsafe，本质上Unsafe类会间接调用jdk.internal.misc包下面Unsafe类来实现。

唤醒节点
注意for循环中的逻辑：unparkSuccessor(Node) 从尾部开始向前遍历，找到最前的一个处于正常阻塞状态的结点，直到节点重合（即等于当前节点） 。 为什么要从尾部开始向前遍历？带着疑问继续往下看…

/*** Wakes up node's successor, if one exists.** @param node the node*/private void unparkSuccessor(Node node) {/** If status is negative (i.e., possibly needing signal) try* to clear in anticipation of signalling.  It is OK if this* fails or if status is changed by waiting thread.*/int ws = node.waitStatus;if (ws < 0)compareAndSetWaitStatus(node, ws, 0);/** Thread to unpark is held in successor, which is normally* just the next node.  But if cancelled or apparently null,* traverse backwards from tail to find the actual* non-cancelled successor.*/Node s = node.next;if (s == null || s.waitStatus > 0) {s = null;// 从尾节点开始从后往前找最近非取消状态节点for (Node t = tail; t != null && t != node; t = t.prev)if (t.waitStatus <= 0)  // 最近非取消状态节点（CANCELLED = 1）s = t;}if (s != null)LockSupport.unpark(s.thread);}

高并发下入队逻辑
既然采用了从尾部遍历的逻辑，那么肯定是为了解决可能会出现的问题。而这个问题就在enq(…)方法中

private Node enq(final Node node) {for (;;) {Node t = tail;if (t == null) { // Must initialize//队列为空需要初始化，创建空的头节点if (compareAndSetHead(new Node()))tail = head;} else {node.prev = t;   							     // ①//set尾部节点if (compareAndSetTail(t, node)) {//当前节点置为尾部   ②t.next = node; //前驱节点的next指针指向当前节点    ③return t;}}}
}enq 方法都是没有进行存在并发安全的问题。 原 CLH 算法并没有 next 引用, Doug Lea 在此做出了优化, 
但是不保证一个结点通过 next 引用一定能其后继结点. 可以理解为一次快速尝试. 但是由于 prev 是可靠的, 因而我们一定能通过从 tail 开始反向遍历的方式找到一个结点.① 处将新结点 node 的 prev 引用指向当前的 t, 即 tail 结点. 然而, 由于 ①, ② 这两行代码的合在一起并非原子性的, 
所以很有可能在设置 tail 时存在着竞争, 也即 tail 被其它线程更新过了. 所以要自旋操作, 即在死循环中操作, 直到成功为止. 
自旋地 CAS volatile 变量是很经典的用法. 如果设置成功了, 那么 从 node.prev 执行完毕到正在用 CAS 设置 tail 时, 
tail 变量是没有被修改的, 所以如果 CAS成功, 那么 node.prev = t 一定是指向上一个 tail 的. 
同样的, ②, ③ 合在一起也并非原子操作, 更重要的是, next field 的设置发生在 CAS 操作之后, 所以可能会存在 tail 已经更新, 
但是 last tail 的 next field 还未设置完毕, 即它的 lastTail.next 为 null 这种情况. 
因此如果此时访问该结点的 next 引用可能就会得到它在队尾, 不存在后继结点; 所以上面释放锁是从tail开始循环查找的compareAndSetTail(t, node) 假如设置成功， t节点中的变量还是原来的数据值还没有发生变化。还是上一个尾节点的数据值 源码： java.util.concurrent.locks.AbstractQueuedSynchronizer.Node/*** Link to the successor node that the current node/thread* unparks upon release. Assigned during enqueuing, adjusted* when bypassing cancelled predecessors, and nulled out (for* sake of GC) when dequeued.  The enq operation does not* assign next field of a predecessor until after attachment,* so seeing a null next field does not necessarily mean that* node is at end of queue. However, if a next field appears* to be null, we can scan prev's from the tail to* double-check.  The next field of cancelled nodes is set to* point to the node itself instead of null, to make life* easier for isOnSyncQueue.*/volatile Node next;