Java锁机制

1. 线程安全

  “线程安全”这个名称，相信稍有经验的程序员都听说过，甚至在代码编写和走查的时候可能还会经常挂在嘴边，但是如何找到一个不太拗口的概念来定义线程安全却不是一件容易的事情。

  笔者认为《Java并发编程实战（Java Concurrency In Practice）》的作者Brian Goetz为“线程安全”做出了一个比较恰当的定义：“当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。”

2. 线程安全的实现方法

  了解过什么是线程安全之后，紧接着的一个问题就是我们应该如何实现线程安全。虚拟机提供的同步和锁机制在这里起到了至关重要的作用。

2.1 互斥同步 （synchronized、ReentrantLock）

  互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段。

• 同步：在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用。
• 互斥：是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。

  因此在“互斥同步”这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

  在Java里面，最基本的互斥同步手段就是synchronized关键字，这是一种块结构（BlockStructured）的同步语法。synchronized关键字经过Javac编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。如果Java源码中的synchronized明确指定了对象参数，那就以这个对象的引用作为reference；如果没有明确指定，那将根据synchronized修饰的方法类型（如实例方法或类方法），来决定是取代码所在的对象实例还是取类型对应的Class对象来作为线程要持有的锁。

  根据《Java虚拟机规范》的要求，在执行monitorenter指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行monitorexit指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

• 被synchronized修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进入同步块也不会出现自己把自己锁死的情况。（PS：重入锁）
• 被synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。

  从执行成本的角度看，持有锁是一个重量级（Heavy-Weight）的操作。在我们知道了在主流Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免地陷入用户态到核心态的转换中，进行这种状态转换需要耗费很多的处理器时间。尤其是对于代码特别简单的同步块，状态转换消耗的时间甚至会比用户代码本身执行的时间还要长。因此才说，synchronized是Java语言中一个重量级的操作，有经验的程序员都只会在确实必要的情况下才使用这种操作。而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，以避免频繁地切入核心态之中。稍后我们会专门介绍Java虚拟机锁优化的措施。

  自JDK 5起（实现了JSR 166 [1] ），Java类库中新提供了java.util.concurrent包（下文称J.U.C包），其中的java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段。基于Lock接口，用户能够以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面去实现同步，这也为日后扩展出不同调度算法、不同特征、不同性能、不同语义的各种锁提供了广阔的空间。

  ReentrantLock(重入锁)：是Lock接口最常见的一种实现，顾名思义，它与synchronized一样是可重入的。在基本用法上，ReentrantLock也与synchronized很相似，只是代码写法上稍有区别而已。不过，ReentrantLock与synchronized相比增加了一些高级功能，主要有以下三项：等待可中断、可实现公平锁及锁可以绑定多个条件。

• 等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。
• 公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock在默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。不过一旦使用了公平锁，将会导致ReentrantLock的性能急剧下降，会明显影响吞吐量。
• 锁绑定多个条件：是指一个ReentrantLock对象可以同时绑定多个Condition对象。在synchronized中，锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁；而ReentrantLock则无须这样做，多次调用newCondition()方法即可。

  JDK6之前synchronized性能是不如ReentrantLock的，当JDK 6中加入了大量针对synchronized锁的优化措施（下一节我们就会讲解这些优化措施）之后，相同的测试中就发现synchronized与ReentrantLock的性能基本上能够持平，至于它们的工作模式，性能分析我们在后面会详细介绍。

2.2 非阻塞同步 （CAS）

  互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步（Blocking Synchronization）。从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销。

  随着硬件指令集的发展，我们已经有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为非阻塞同步（Non-Blocking Synchronization），使用这种措施的代码也常被称为无锁（Lock-Free）编程。

  为什么笔者说使用乐观并发策略需要“硬件指令集的发展”？因为我们必须要求操作和冲突检测这两个步骤具备原子性。靠什么来保证原子性？如果这里再使用互斥同步来保证就完全失去意义了，所以我们只能靠硬件来实现这件事情，硬件保证某些从语义上看起来需要多次操作的行为可以只通过一条处理器指令就能完成，这类指令常用的有：

• 测试并设置（Test-and-Set）；
• 获取并增加（Fetch-and-Increment）；
• 交换（Swap）；
• 比较并交换（Compare-and-Swap，下文称CAS）；
• 加载链接/条件储存（Load-Linked/Store-Conditional，下文称LL/SC）。

  其中，前面的三条是20世纪就已经存在于大多数指令集之中的处理器指令，后面的两条是现代处理器新增的，而且这两条指令的目的和功能也是类似的。在IA64、x86指令集中有用cmpxchg指令完成的CAS功能，在SPARC-TSO中也有用casa指令实现的，而在ARM和PowerPC架构下，则需要使用一对ldrex/strex指令来完成LL/SC的功能。因为Java里最终暴露出来的是CAS操作，所以我们以CAS指令为例进行讲解。

  CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。

  在JDK 5之后，Java类库中才开始使用CAS操作，该操作由sun.misc.Unsafe类里面的compareAndSwapInt()和compareAndSwapLong()…等几个方法包装提供。HotSpot虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的过程，或者可以认为是无条件内联进去了

  尽管CAS看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？这是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA问题”。

3. 锁优化

  高效并发是从JDK 5升级到JDK 6后一项重要的改进项，HotSpot虚拟机开发团队在这个版本上花费了大量的资源去实现各种锁优化技术，如适应性自旋（Adaptive Spinning）、锁消除（LockElimination）、锁膨胀（Lock Coarsening）、轻量级锁（Lightweight Locking）、偏向锁（BiasedLocking）等，这些技术都是为了在线程之间更高效地共享数据及解决竞争问题，从而提高程序的执行效率。

3.1 自旋锁与自适应自旋

  前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性能带来了很大的压力。同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。现在绝大多数的个人电脑和服务器都是多路（核）处理器系统，如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

  在JDK 6中synchronized自旋策略默认开启了。自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，所以如果锁被占用的时间很短，自旋等待的效果就会非常好，反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，这就会带来性能的浪费。自旋次数的默认值是十次，用户也可以使用参数-XX：PreBlockSpin来自行更改。

  在JDK 6中对自旋锁的优化，引入了自适应的自旋。自适应意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。有了自适应自旋，随着程序运行时间的增长及性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越精准，虚拟机就会变得越来越“聪明”了。

3.2 锁消除

  锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。

3.3 锁粗化

  原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。
  大多数情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。这种情况还不如只加一次锁，包含多个加锁代码块，这就是锁粗化。

  连续的append()方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。

3.4 轻量级锁

  轻量级锁是JDK 6时加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为“重量级”锁。

  轻量级锁适用场景：在同一时间，只有两条线程竞争锁（此时另一个线程还是自旋状态），或者不同时间段有不同的线程获取锁，不存在竞争。此时根本就用不需要阻塞线程，连monitor 对象都不需要，所以就引入了轻量级锁这个概念，避免了系统调用，减少了开销。

  HotSpot虚拟机的对象头（Object Header）分为两部分，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄（Generational GC Age）等。这部分数据的长度在32位和64位的Java虚拟机中分别会占用32个或64个比特，官方称它为“MarkWord”。考虑到Java虚拟机的空间使用效率，Mark Word被设计成一个非固定的动态数据结构，以便在极小的空间内存储尽量多的信息。它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机中，对象未被锁定的状态下，Mark Word的32个比特空间里的25个比特将用于存储对象哈希码，4个比特用于存储对象分代年龄，2个比特用于存储锁标志位，还有1个比特固定为0（这表示未进入偏向模式）。对象除了未被锁定的正常状态外，还有轻量级锁定、重量级锁定、GC标记、可偏向等几种不同状态，这些状态下对象头的存储内容如下表所示。

​ HotSpot虚拟机对象头Mark Word

  我们简单回顾了对象的内存布局后，接下来就可以介绍轻量级锁的工作过程了：在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方为这份拷贝加了一个Displaced前缀，即Displaced Mark Word），这时候线程堆栈与对象头的状态如下图所示。

​ 轻量级锁CAS操作之前堆栈与对象的状态

  然后，虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。这时候线程堆栈与对象头的状态如下图所示。

​ 轻量级锁CAS操作之后堆栈与对象的状态

  它的解锁过程也同样是通过CAS操作来进行的，如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的DisplacedMark Word替换回来。假如能够成功替换，那整个同步过程就顺利完成了

3.4.1 锁膨胀，重量级锁

 轻量级锁膨胀有两种可能：

• 在锁竞争时，未获取锁的线程会采用CAS自旋方式获取锁、但是如果当前线程自旋次数过多，轻量级锁也会升级为重量级锁。
• 如果出现两条以上的线程争用同一个锁的情况，那轻量级锁不再有效，必须膨胀为重量级锁。

  竞争的线程去申请一个monitor（重量级锁），然后把锁对象的Mark Word替换成指向monitor的指针，修改锁标志的状态值变为“10”（Mark Word的最后两个比特），同时把_owner设置为持有轻量锁的线程，之后当前线程还会自旋使用CAS操作将_owner指向自己（自旋的目的是为了抢锁），自旋失败则进入_EntryList开始等待，线程1被挂起。当持有锁的线程cas操作解锁失败，也就是发现锁已经升级为重量级别了，那么它会将_owner设置为null，再去唤醒_EntryList里面的线程。（PS：_EntryList是个队列，这里只会唤醒第一个节点的线程，唤醒多个只会增加抢占开销。在解锁将_owner设置为null时，也可能会有新线程抢占将_owner设置为自己，所以这步骤是发生synchronized非公平锁关键所在）

  monitor对象如下所示：

3.5 偏向锁

  偏向锁也是JDK 6中引入的一项锁优化措施，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。

   偏向锁适用场景：第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束。（PS：另一个线程发现 ，mark word 偏向模式是 1，尝试使用 cas s替换线程id，失败后偏向模式马上宣告结束）

  偏向锁的原理：假设当前虚拟机启用了偏向锁（启用参数-XX：+UseBiased Locking，这是自JDK 6起HotSpot虚拟机的默认值），那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对Mark Word的更新操作等）。

  当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求 时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor类里有字段可以记录非加锁状态（标志位为“01”）下的Mark Word，其中自然可以存储原来的哈希码。

偏向锁不会“不会主动释放锁”，但是会被撤销：

  程序最开始如果只有一个线程A去访问synchronized时，如果对象是可偏向状态，线程A使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。当另外一个线程B来竞争锁，它发现线程id不是自己的，这时会进入以下步骤：

1. 查看偏向的线程是否存活，如果已经不存活了，则直接撤销偏向锁，进入无锁状态，之后线程B将锁升级为轻量级锁。JVM维护了一个集合存放所有存活的线程，通过遍历该集合判断某个线程是否存活
2. 偏向的线程是否还在同步块中，如果不在了，则撤销偏向锁，进入无锁状态。我们回顾一下偏向锁的加锁流程：每次进入同步块（即执行monitorenter）的时候都会以从高往低的顺序在栈中找到第一个可用的Lock Record，将其obj字段指向锁对象。每次解锁（即执行monitorexit）的时候都会将最低的一个相关Lock Record移除掉。所以可以通过遍历线程栈中的Lock Record来判断线程是否还在同步块中。
3. 如果还在同步代码块中，竞争者线程向JVM提交一个时间停止的请求；在时间停止的时候（safe point），JVM线程伪造一个displaced mark word到持有锁的线程的栈上，object的mark work更新为轻量锁模式。然后唤醒持有锁的线程。这样持有锁的线程就会自以为自己持有的是轻量锁了。而竞争者也会按照轻量锁的模式去竞争锁。

​ 偏向锁、轻量级锁的状态转化及对象Mark Word的关系

锁升级过程解读：
  当第一条线程A过来抢锁，发现对象 mark word 偏向模式 = 1，线程A使用 CAS 操作替换自己的线程ID成功，锁状态从无锁进入到偏向锁状态

  当第二条线程B过来抢锁，发现 mark word 偏向模式 = 1，使用 CAS 操作替换自己的线程ID失败，然后检查线程A是否还在同步块，不在则撤销偏向模式，mark word 偏向模式 = 0，但因为线程B还得抢锁，线程B在栈帧创建Lock Record，使用 CAS 操作用 lock record 指针替换 mark word 成功，并且设置 mark word 标志位 = 01，锁状态从无锁进入到轻量级锁。

  当线程C过来抢锁，发现无偏向模式，使用 CAS 操作来获取 mark word 失败，自旋一段时间后或有另外一个线程来竞争锁，将会申请 monitor，然后把锁对象的 Mark Word 位置替换成指向monitor 的指针，同时把_owner设置为持有轻量锁的线程B，并且把 Mark Word 的标志位 = 10，锁状态从轻量锁升级为重量级锁，这时线程C还会尝试自旋获取锁，当失败则会加入_EntryList等待队列，线程被挂起。

4. ReentrantLock锁工作原理流程图

总结：两者其实大相径庭的

• 在策略上，两者都有CAS操作自旋策略，但synchronized有自适应自旋，以及偏向锁无同步模式，而ReentrantLock自旋次数比较少；
• 在修改锁定标志上，synchronized在轻量级是通过在栈帧建立一个名为锁记录（Lock Record）的空间，通过cas操作修改Mark word指向Lock Record，并保存旧的Mark Word、在重量级操作是通过cas操作修改ObjectMonitor对象的_owner指向，而ReentrantLock则是通过CAS操作修改state属性值，并设置当前拥有锁的线程；
• 在锁竞争时，它们同样都有线程状态切换的开销。
• 在功能上ReentrantLock则是synchronized的超集

5. ReentrantLock和synchronized性能测试对比

// TODO

总结：

• 线程状态Runnable和Blocked状态相互转换，会设计用户态到内核态的转换，也就是系统调用内核线程挂起，同时让出的cpu要执行新的内核线程任务，这时也避免不了内核线程上下文切换。其实在我们用户程序中系统调用是非常频繁，相对于内核线程上下文切换损失的性能也更小。

• 系统调用、内核线程上下文切换可以看这篇文章：系统调用、内核线程上下文切换

• synchronized底层源码可以看这篇文章：synchronized底层源码