前言

记得开始学习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作者发现的“大多数锁只会由同一线程并发申请”的教训法则。

锁的优劣