共计 8830 个字符，预计需要花费 23 分钟才能阅读完成。
前言
记得开始学习 Java 的时候，一遇到多线程状况就应用 synchronized，绝对于过后的咱们来说 synchronized 是这么的神奇而又弱小，那个时候咱们赋予它一个名字“同步”，也成为了咱们解决多线程状况的百试不爽的良药。然而，随着学习的进行咱们晓得在 JDK1.5 之前 synchronized 是一个重量级锁，绝对于 j.u.c.Lock，它会显得那么轻便，以至于咱们认为它不是那么的高效而缓缓摒弃它。
不过，随着 Javs SE 1.6 对 synchronized 进行的各种优化后，synchronized 并不会显得那么重了。上面来一起摸索 synchronized 的根本应用、实现机制、Java 是如何对它进行了优化、锁优化机制、锁的存储构造等降级过程。
1 根本应用
Synchronized 是 Java 中解决并发问题的一种最罕用的办法，也是最简略的一种办法。Synchronized 的作用次要有三个：
从语法上讲，Synchronized 能够把任何一个非 null 对象作为 ” 锁 ”，在 HotSpot JVM 实现中，锁有个专门的名字：对象监视器（Object Monitor）。
Synchronized 总共有三种用法：
留神，synchronized 内置锁 是一种 对象锁（锁的是对象而非援用变量），作用粒度是对象 ，能够用来实现对 临界资源的同步互斥拜访 ，是 可重入 的。 其可重入最大的作用是防止死锁，如：
2 同步原理
数据同步须要依赖锁，那锁的同步又依赖谁？synchronized 给出的答案是在软件层面依赖 JVM，而 j.u.c.Lock 给出的答案是在硬件层面依赖非凡的 CPU 指令。
当一个线程拜访同步代码块时，首先是须要失去锁能力执行同步代码，当退出或者抛出异样时必须要开释锁，那么它是如何来实现这个机制的呢？咱们先看一段简略的代码：
查看反编译后后果：
反编译后果
1.monitorenter：每个对象都是一个监视器锁（monitor）。当 monitor 被占用时就会处于锁定状态，线程执行 monitorenter 指令时尝试获取 monitor 的所有权，过程如下：
2.monitorexit：执行 monitorexit 的线程必须是 objectref 所对应的 monitor 的所有者。指令执行时，monitor 的进入数减 1，如果减 1 后进入数为 0，那线程退出 monitor，不再是这个 monitor 的所有者。其余被这个 monitor 阻塞的线程能够尝试去获取这个 monitor 的所有权。
通过下面两段形容，咱们应该能很分明的看出 Synchronized 的实现原理，Synchronized 的语义底层是通过一个 monitor 的对象来实现，其实 wait/notify 等办法也依赖于 monitor 对象 ，这就是为什么只有在同步的块或者办法中能力调用 wait/notify 等办法， 否则会抛出 java.lang.IllegalMonitorStateException 的异样的起因。
再来看一下同步办法：
查看反编译后后果：
反编译后果
从编译的后果来看，办法的同步并没有通过指令 _**monitorenter**_ 和 _monitorexit_ 来实现（实践上其实也能够通过这两条指令来实现），不过绝对于一般办法，其常量池中多了 **_ACC_SYNCHRONIZED_** 标示符。JVM 就是依据该标示符来实现办法的同步的：
两种同步形式实质上没有区别，只是办法的同步是一种隐式的形式来实现，无需通过字节码来实现。两个指令的执行是 JVM 通过调用操作系统的互斥原语 mutex 来实现，被阻塞的线程会被挂起、期待从新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。
3 同步概念
3.1 Java 对象头
在 JVM 中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下图所示：
Synchronized 用的锁就是存在 Java 对象头里的，那么什么是 Java 对象头呢？Hotspot 虚拟机的对象头次要包含两局部数据：Mark Word（标记字段）、Class Pointer（类型指针）。其中 Class Pointer 是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word 用于存储对象本身的运行时数据，它是实现轻量级锁和偏差锁的要害。Java 对象头具体构造形容如下：
Java 对象头构造组成
Mark Word 用于存储对象本身的运行时数据，如：哈希码（HashCode）、GC 分代年龄、锁状态标记、线程持有的锁、偏差线程 ID、偏差工夫戳等 。下图是 Java 对象头 无锁状态下 Mark Word 局部的存储构造（32 位虚拟机）：
Mark Word 存储构造
对象头信息是与对象本身定义的数据无关的额定存储老本，然而思考到虚拟机的空间效率，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会依据对象的状态复用本人的存储空间，也就是说，Mark Word 会随着程序的运行发生变化，可能变动为存储以下 4 种数据：
Mark Word 可能存储 4 种数据
在 64 位虚拟机下，Mark Word 是 64bit 大小的，其存储构造如下：
64 位 Mark Word 存储构造
对象头的最初两位存储了锁的标记位，01 是初始状态，未加锁 ，其对象头里存储的是对象自身的哈希码，随着锁级别的不同，对象头里会存储不同的内容。 偏差锁存储的是以后占用此对象的线程 ID；而轻量级则存储指向线程栈中锁记录的指针 。从这里咱们能够看到，“锁”这个货色， 可能是个锁记录 + 对象头里的援用指针 （判断线程是否领有锁时将线程的锁记录地址和对象头里的指针地址比拟)， 也可能是对象头里的线程 ID（判断线程是否领有锁时将线程的 ID 和对象头里存储的线程 ID 比拟）。
HotSpot 虚拟机对象头 Mark Word
3.2 对象头中 Mark Word 与线程中 Lock Record
在线程进入同步代码块的时候，如果此同步对象没有被锁定，即它的锁标记位是 01，则虚拟机首先在以后线程的栈中创立咱们称之为“锁记录（Lock Record）”的空间，用于存储锁对象的 Mark Word 的拷贝 ，官网把这个拷贝称为 Displaced Mark Word。 整个 Mark Word 及其拷贝至关重要。
Lock Record 是线程公有的数据结构 ，每一个线程都有一个可用 Lock Record 列表，同时还有一个全局的可用列表。 每一个被锁住的对象 Mark Word 都会和一个 Lock Record 关联（对象头的 MarkWord 中的 Lock Word 指向 Lock Record 的起始地址），同时 Lock Record 中有一个 Owner 字段寄存领有该锁的线程的惟一标识（或者object mark word），示意该锁被这个线程占用。如下图所示为 Lock Record 的内部结构：
3.3 监视器（Monitor）
任何一个对象都有一个 Monitor 与之关联，当且一个 Monitor 被持有后，它将处于锁定状态 。Synchronized 在 JVM 里的实现都是 基于进入和退出 Monitor 对象来实现办法同步和代码块同步，尽管具体实现细节不一样，然而都能够通过成对的 MonitorEnter 和 MonitorExit 指令来实现。
那什么是 Monitor？能够把它了解为 一个同步工具 ，也能够形容为 一种同步机制 ，它通常被 形容为一个对象。
与所有皆对象一样，所有的 Java 对象是天生的 Monitor，每一个 Java 对象都有成为 Monitor 的潜质，因为在 Java 的设计中，每一个 Java 对象自打娘胎里进去就带了一把看不见的锁，它叫做外部锁或者 Monitor 锁。
也就是通常说 Synchronized 的对象锁，MarkWord 锁标识位为 10，其中指针指向的是 Monitor 对象的起始地址。在 Java 虚拟机（HotSpot）中，Monitor 是由 ObjectMonitor 实现的，其次要数据结构如下（位于 HotSpot 虚拟机源码 ObjectMonitor.hpp 文件，C++ 实现的）：
ObjectMonitor 中有两个队列，_WaitSet 和 _EntryList，用来保留 ObjectWaiter 对象列表（每个期待锁的线程都会被封装成 ObjectWaiter 对象），_owner 指向持有 ObjectMonitor 对象的线程，当多个线程同时拜访一段同步代码时：
同时，Monitor 对象存在于每个 Java 对象的对象头 Mark Word 中（存储的指针的指向），Synchronized 锁便是通过这种形式获取锁的 ，也是为什么 Java 中任意对象能够作为锁的起因， 同时 notify/notifyAll/wait 等办法会应用到 Monitor 锁对象，所以必须在同步代码块中应用。
监视器 Monitor 有两种同步形式：互斥与合作 。多线程环境下线程之间如果须要共享数据，须要解决互斥拜访数据的问题， 监视器能够确保监视器上的数据在同一时刻只会有一个线程在拜访。
什么时候须要合作？ 比方：
如上图所示，一个线程通过 1 号门进入 Entry Set(入口区)，如果在入口区没有线程期待，那么这个线程就会获取监视器成为监视器的 Owner，而后执行监督区域的代码。如果在入口区中有其它线程在期待，那么新来的线程也会和这些线程一起期待。线程在持有监视器的过程中，有两个抉择，一个是失常执行监视器区域的代码 ，开释监视器，通过 5 号门退出监视器； 还有可能期待某个条件的呈现，于是它会通过 3 号门到 Wait Set（期待区）劳动，直到相应的条件满足后再通过 4 号门进入从新获取监视器再执行。
留神：
4 锁的优化
从 JDK5 引入了古代操作系统新减少的 CAS 原子操作（JDK5 中并没有对 synchronized 关键字做优化，而是体现在 J.U.C 中，所以在该版本 concurrent 包有更好的性能 ），从 JDK6 开始，就对 synchronized 的实现机制进行了较大调整， 包含应用 JDK5 引进的 CAS 自旋之外，还减少了自适应的 CAS 自旋、锁打消、锁粗化、偏差锁、轻量级锁这些优化策略。因为此关键字的优化使得性能极大进步，同时语义清晰、操作简略、无需手动敞开，所以举荐在容许的状况下尽量应用此关键字，同时在性能上此关键字还有优化的空间。
锁次要存在四种状态，顺次是：无锁状态、偏差锁状态、轻量级锁状态、重量级锁状态 ，锁能够从偏差锁降级到轻量级锁，再降级的重量级锁。 然而锁的降级是单向的，也就是说只能从低到高降级，不会呈现锁的降级。
4.1 自旋锁
线程的阻塞和唤醒须要 CPU 从用户态转为外围态 ，频繁的阻塞和唤醒对 CPU 来说是一件累赘很重的工作，势必会给零碎的并发性能带来很大的压力。同时咱们发现在许多利用下面， 对象锁的锁状态只会继续很短一段时间，为了这一段很短的工夫频繁地阻塞和唤醒线程是十分不值得的。
所以引入自旋锁，何谓自旋锁？
自旋锁实用于锁爱护的临界区很小的状况，临界区很小的话，锁占用的工夫就很短 。自旋期待不能代替阻塞，尽管它能够防止线程切换带来的开销，然而它占用了 CPU 处理器的工夫。 如果持有锁的线程很快就开释了锁，那么自旋的效率就十分好，反之，自旋的线程就会白白消耗掉解决的资源 ，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的节约。所以说， 自旋期待的工夫（自旋的次数）必须要有一个限度，如果自旋超过了定义的工夫依然没有获取到锁，则应该被挂起。
自旋锁在 JDK 1.4.2 中引入，默认敞开 ，然而能够应用 -XX:+UseSpinning 开开启， 在 JDK1.6 中默认开启 。同时自旋的默认次数为 10 次， 能够通过参数 -XX:PreBlockSpin 来调整。
如果通过参数 -XX:PreBlockSpin 来调整自旋锁的自旋次数，会带来诸多不便。如果将参数调整为 10，然而零碎很多线程都是等你刚刚退出的时候就开释了锁（如果多自旋一两次就能够获取锁），是不是很难堪。于是 JDK1.6 引入自适应的自旋锁，让虚构机会变得越来越聪慧。
4.2 适应性自旋锁
JDK 1.6 引入了更加聪慧的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋工夫及锁的拥有者的状态来决定。那它如何进行适应性自旋呢？
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的情况预测会越来越精确，虚构机会变得越来越聪慧。
4.3 锁打消
为了保证数据的完整性，在进行操作时须要对这部分操作进行同步控制，然而在有些状况下，JVM 检测到不可能存在共享数据竞争，这是 JVM 会对这些同步锁进行锁打消。
如果不存在竞争，为什么还须要加锁呢？所以锁打消能够节俭毫无意义的申请锁的工夫。变量是否逃逸，对于虚拟机来说须要应用数据流剖析来确定，然而对于程序员来说这还不分明么？在明明晓得不存在数据竞争的代码块前加上同步吗？然而有时候程序并不是咱们所想的那样？尽管没有显示应用锁，然而在应用一些 JDK 的内置 API 时，如 StringBuffer、Vector、HashTable 等，这个时候会存在隐形的加锁操作。比方 StringBuffer 的 append()办法，Vector 的 add()办法：
在运行这段代码时，JVM 能够显著检测到变量 vector 没有逃逸出办法 vectorTest()之外，所以 JVM 能够大胆地将 vector 外部的加锁操作打消。
4.4 锁粗化
在应用同步锁的时候，须要让同步块的作用范畴尽可能小—仅在共享数据的理论作用域中才进行同步，这样做的目标是 为了使须要同步的操作数量尽可能放大，如果存在锁竞争，那么期待锁的线程也能尽快拿到锁。
在大多数的状况下，上述观点是正确的。然而如果一系列的间断加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。
如下面实例：
4.5 偏差锁
偏差锁是 JDK6 中的重要引进，因为 HotSpot 作者通过钻研实际发现，在大多数状况下，锁不仅不存在多线程竞争，而且总是由同一线程屡次取得，为了让线程取得锁的代价更低，引进了偏差锁。
偏差锁是在单线程执行代码块时应用的机制，如果在多线程并发的环境下（即线程 A 尚未执行完同步代码块，线程 B 发动了申请锁的申请），则肯定会转化为轻量级锁或者重量级锁。
在 JDK5 中偏差锁默认是敞开的，而到了 JDK6 中偏差锁曾经默认开启。如果并发数较大同时同步代码块执行工夫较长，则被多个线程同时拜访的概率就很大，就能够应用参数 -XX:-UseBiasedLocking 来禁止偏差锁(但这是个 JVM 参数，不能针对某个对象锁来独自设置)。
引入偏差锁次要目标是：为了在没有多线程竞争的状况下尽量减少不必要的轻量级锁执行门路 。因为轻量级锁的加锁解锁操作是须要依赖屡次 CAS 原子指令的， 而偏差锁只须要在置换 ThreadID 的时候依赖一次 CAS 原子指令（因为一旦呈现多线程竞争的状况就必须撤销偏差锁，所以偏差锁的撤销操作的性能损耗也必须小于节省下来的 CAS 原子指令的性能耗费）。
那么偏差锁是如何来缩小不必要的 CAS 操作呢？首先咱们看下无竞争下锁存在什么问题：
CAS 为什么会引入本地提早？这要从 SMP（对称多处理器）架构说起，下图大略表明了 SMP 的构造：
SMP（对称多处理器）架构
而 CAS 的全称为 Compare-And-Swap，是一条 CPU 的原子指令，其作用是让 CPU 比拟后原子地更新某个地位的值，通过考察发现，其实现形式是基于硬件平台的汇编指令，就是说 CAS 是靠硬件实现的，JVM 只是封装了汇编调用，那些 AtomicInteger 类便是应用了这些封装后的接口。
例如：Core1 和 Core2 可能会同时把主存中某个地位的值 Load 到本人的 L1 Cache 中，当 Core1 在本人的 L1 Cache 中批改这个地位的值时，会通过总线，使 Core2 中 L1 Cache 对应的值“生效”，而 Core2 一旦发现自己 L1 Cache 中的值生效（称为 Cache 命中缺失）则会通过总线从内存中加载该地址最新的值，大家通过总线的来回通信称为“Cache 一致性流量”，因为总线被设计为固定的“通信能力”，如果 Cache 一致性流量过大，总线将成为瓶颈 。而当 Core1 和 Core2 中的值再次统一时，称为“Cache 一致性”， 从这个层面来说，锁设计的终极目标便是缩小 Cache 一致性流量。
而 CAS 恰好会导致 Cache 一致性流量，如果有很多线程都共享同一个对象，当某个 Core CAS 胜利时必然会引起总线风暴，这就是所谓的本地提早，实质上偏差锁就是为了打消 CAS，升高 Cache 一致性流量。
Cache 一致性：
**
Cache 一致性流量的例外情况：
**
NUMA(Non Uniform Memory Access Achitecture）架构：
所以，当一个线程拜访同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏差的线程 ID，当前该线程进入和退出同步块时不须要破费 CAS 操作来抢夺锁资源，只须要查看是否为偏差锁、锁标识为以及 ThreadID 即可，解决流程如下：
偏差锁的开释采纳了 一种只有竞争才会开释锁的机制，线程是不会被动去开释偏差锁，须要期待其余线程来竞争 。偏差锁的撤销须要 期待全局平安点（这个工夫点是上没有正在执行的代码）。其步骤如下：
偏差锁的获取和开释过程
4.6 轻量级锁
引入轻量级锁的次要目标是 在没有多线程竞争的前提下，缩小传统的重量级锁应用操作系统互斥量产生的性能耗费。当敞开偏差锁性能或者多个线程竞争偏差锁导致偏差锁降级为轻量级锁，则会尝试获取轻量级锁，其步骤如下：
1. 在线程进入同步块时，如果同步对象锁状态为无锁状态（锁标记位为“01”状态，是否为偏差锁为“0”），虚拟机首先将在以后线程的栈帧中建设一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝，官网称之为 Displaced Mark Word。此时线程堆栈与对象头的状态如下图所示：
轻量级锁 CAS 操作之前线程堆栈与对象的状态
2. 拷贝对象头中的 Mark Word 复制到锁记录（Lock Record）中；
3. 拷贝胜利后，虚拟机将应用 CAS 操作尝试将对象 Mark Word 中的 Lock Word 更新为指向以后线程 Lock Record 的指针，并将 Lock record 里的 owner 指针指向 object mark word。如果更新胜利，则执行步骤（4），否则执行步骤（5）；
4. 如果这个更新动作胜利了，那么以后线程就领有了该对象的锁，并且对象 Mark Word 的锁标记位设置为“00”，即示意此对象处于轻量级锁定状态，此时线程堆栈与对象头的状态如下图所示：
轻量级锁 CAS 操作之后线程堆栈与对象的状态
5.如果这个更新操作失败了，虚拟机首先会查看对象 Mark Word 中的 Lock Word 是否指向以后线程的栈帧 ，如果是，就阐明以后线程曾经领有了这个对象的锁，那就能够间接进入同步块继续执行。 否则阐明多个线程竞争锁，进入自旋执行（3），若自旋完结时仍未取得锁，轻量级锁就要收缩为重量级锁，锁标记的状态值变为“10”，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，以后线程以及前面期待锁的线程也要进入阻塞状态。
轻量级锁的开释也是通过 CAS 操作来进行的，次要步骤如下：
对于轻量级锁，其性能晋升的根据是 “对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，如果突破这个根据则除了互斥的开销外，还有额定的 CAS 操作，因而在有多线程竞争的状况下，轻量级锁比重量级锁更慢。
轻量级锁的获取和开释过程
1. 为什么降级为轻量锁时要把对象头里的 Mark Word 复制到线程栈的锁记录中呢？
2. 为什么会尝试 CAS 不胜利以及什么状况下会不胜利？
此处，如何了解“轻量级”？“轻量级”是绝对于应用操作系统互斥量来实现的传统锁而言的 。然而，首先须要强调一点的是， 轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，缩小传统的重量级锁应用产生的性能耗费。
4.7 重量级锁
Synchronized 是通过对象外部的一个叫做 监视器锁（Monitor）来实现的 。 然而监视器锁实质又是依赖于底层的操作系统的 Mutex Lock 来实现的。而操作系统实现线程之间的切换这就须要从用户态转换到外围态，这个老本十分高，状态之间的转换须要绝对比拟长的工夫，这就是为什么 Synchronized 效率低的起因。因而，这种依赖于操作系统 Mutex Lock 所实现的锁咱们称之为 “重量级锁”。
4.8 重量级锁、轻量级锁和偏差锁之间转换
重量级锁、轻量级锁和偏差锁之间转换
Synchronized 偏差锁、轻量级锁及重量级锁转换流程
5 锁的优劣
各种锁并不是互相代替的，而是在不同场景下的不同抉择 ，相对不是说重量级锁就是不适合的。 每种锁是只能降级，不能降级，即由偏差锁 -> 轻量级锁 -> 重量级锁，而这个过程就是开销逐步加大的过程。
在第 3 种状况下进入同步代码块就 要做偏差锁建设、偏差锁撤销、轻量级锁建设、降级到重量级锁，最终还是得靠重量级锁来解决问题，那这样的代价就比间接用重量级锁要大不少了 。所以应用哪种技术，肯定要看其所处的环境及场景， 在绝大多数的状况下，偏差锁是无效的，这是基于 HotSpot 作者发现的“大多数锁只会由同一线程并发申请”的教训法则。
锁的优劣