Java语言为了解决并发编程中存在的原子性、可见性和有序性问题，提供了一系列和并发处理相关的关键字，比如synchronized、volatile、final、concurren包等

synchronized是Java提供的一个并发控制的关键字。主要用法有两种，分别是同步方法和同步代码块。

synchronized用法如下：

被synchronized修饰的代码块及方法，不允许被多个线程同时访问。

synchronized，是Java中用于并发情况下数据同步访问的一个重要关键字。当我们想要保证一个共享资源，在同一时间只会被一个线程访问到的时候，我们可以在底阿妈中使用synchronized关键字对类或者对象加锁。那么synchronized关键字到底如何实现上锁的呢？

我们将下述用 synchronized修饰代码块的内容进行反编译：

反编译后，我们将得到如下的字节码指令：

我们主要关注 main() 方法中被synchronized修饰的代码块的字节码指令：

编译后的代码中，出现了一些特别的字节码指令，其中monitorenter字节码指令理解为加锁，monitorexit字节码指令理解为释放锁。每个对象维护者一个记录着被锁次数的计数器（它将被记录在MarkWord中，后续会谈到）。

字节码中为我们自动添加了两处monitorexit指令,第二处的monitorexit指令将在出现异常时被调用，进行锁的释放。（如果我们自己使用其他自定义的锁，也需要在出现异常）

上述指令也反映了：synchronized修饰代码块的时候，不需要我们主动加锁和解锁的字段，因为它自动在代码块开始和结束的地方替我们补充了加锁和解锁的字节码指令，这也是为什么synchronized还被称为内置锁。

我们将下列用synchronized修饰方法的代码进行反编译：

我们将得到：

synchronized除了修饰在代码块上，还可以修饰在方法上。如果synchronized修饰在方法上，同步方法的常量池中会有一个ACC_SYNCHRONIZED标志，当某个线程需要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED标志，如果有，则首先需要获得monitor锁（监视器锁），然后才开始进入临界区，执行方法，方法执行之后再释放monitor锁（监视器锁）。

同样的，如果方法执行过程中遇到异常，并且在方法内部并没有处理该异常，那么再异常被抛到方法外面之前，monitor锁（监视器锁）将会被自动释放。

原子性，即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行

Java内存模型中，有read,load等指令直接保证原子性操作，如果需要更大范围的原子性保证，则可以通过lock和unlock来做块的同步，虚拟机提供了字节码指令monitorenter和monitorexit来隐式地使用lock和unlock这两个操作。反映到Java代码中，就是我们上述提到的synchronized关键字。

可见性，即当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。

Java内存模型通过：1）在变量修改后，将新值同步回主内存；2）在变量读取之前，从主存刷新变量的值。这两种方式来实现可见性。

Java可以通过volatile,synchronized和final来实现可见性。

有序性，即所有指令的执行顺序是有序的

Java可以通过volatile关键字来保证有序性。

原子性

由synchronized修饰的临界区代码是具有原子性的。可能有多个线程争抢执行同一个临界区的代码，但当一个线程持有该临界区的锁时，即使其他正在争抢的线程被线程调度分到时间片，也无法进入临界区。所有其他线程都要等到当前持有锁的线程执行完临界区代码并退出，才有可能在被调度时，争抢到锁并执行临界区代码。

可见性

被synchronized修饰的代码，会在开始执行的时候调用字节码指令monitorenter加锁，执行完成后，会调用字节码指令monitorexit解锁。

为了保证可见性，有一条规则是这样的：“在unlock之前，必须把变量同步回主内存中”，也就是在对一个变量解锁之前，必须先把该变量同步回主存中，这样解锁后，后续线程就可以访问到被修改后的值，从而保证了可见性。

Synchronized 没有有序性

由于处理器优化和指令重排等，CPU有可能对代码进行乱序执行。而需要注意的是，synchronized是无法禁止指令重排和处理器优化的。如果要阻止指令重排等来实现指令执行的有序性，则需要使用到volatile，这不是本章要讨论的内容，不做过多赘述。

对象在实例化之后，是被存放在堆内存中的。这里的对象由三部分组成，如下图：

左边是普通对象，对象头(Object header)包含着MarkWord和类型指针。而数组对象的对象头还多包含了数组长度。

成员变量存储的都是对象的真正的有效数据，也就是各个成员变量属性字段的值，如果拥有父类，还会包含父类的成员变量。

具体对齐填充的规则与JVM有关，在Hotspot中。对象的大小要求向8Byte对齐，当对象长度不足8字节的整数倍时，需要再对象中进行填充操作。

在对象头中，MarkWord一共有64个bit，用于存储对象自身的运行时数据，标记对象处于一下状态中的某一种：

在jdk6之前，通过synchronized关键字加锁的时候，无差别地使用重量级锁，重量级锁会使CPU在用户态和和心态之间频繁切换，有很大的系统消耗。后来随着synchronized的不断优化，提出了锁升级的概念，在MarkWord中，通过锁的标志位来表示当前对象的锁状态。

Integer包装类为什么比 int 基本类型内存占得更多？

Integer实例作为一个对象，对象头（64bit）加上存的整形数据(32bit)以及其他部分，远远超过 int所需的内存（32 bit)

我们知道了MarkWord可以用于锁升级，那么锁升级的过程是如何的呢？

synchronized不断优化中，引入了偏向锁，轻量级锁，重量级锁的概念，在不同的情况逐步进行锁膨胀。过程如下图：

有的对象可能大多使用的场合都只在一个线程中运行，只有少数情况会遇到多线程的竞争，我们不需要直接设置竞争机制，或者直接上消耗资源的锁。我们可以通过偏向锁这样，只在MarkWord上加一个线程ID的标记的低消耗的方式，来标志对象正在被使用。当遇到争抢的时候，再依情况进行锁升级。例如StringBuffer中很多方法都被synchronized修饰，但是它的使用场景经常只在一个线程中执行。

Hotspot JVM中，偏向锁默认是开启的，而且是从程序开始计时起，延迟4s开启。

JVM参数可以开启或者关闭偏向锁：

在IDEA中开启偏向锁

默认偏向锁在程序启动4s后开启。在JVM还没开启偏向锁的时候，如果用synchronized修饰，将会直接升级为轻量级锁。

修改偏向锁延迟时间的JVM操作为：

开启偏向锁后，Java对象被创建后将会是匿名偏向态（可偏向态），未开启偏向锁，Java对象被创建后将会是普通对象（无锁态）。

普通对象的 MarkWord 格式为：

没有开启偏向锁时，当对象首次创建的时候，hashcode、分代年龄均以 0 作为初始值。其中 hashcode 只有被使用的时候，才会被赋予值，例如该对象调用了 hashcode()方法。

偏向锁态的MarkWord格式为：

开启偏向锁后，对象实例化后，还没有线程对它上锁（还没有线程调用的方法对该实例使用synchronized修饰），线程ID 为初始值 0。也就是还没偏向任何一个线程。这个状态被称为 匿名偏向。

此后，第一个对该对象上锁（调用的方法中对该实例使用synchronized修饰）的线程，将会把 线程ID 记录到 MarkWord中。此时MarkWord的偏向锁位被置为 1，且锁标志位为 01。 此时这个对象就可以理解为偏向该线程，为偏向锁态。

当 JVM 的偏向锁开启后，就可以对实例进行偏向锁的加锁。

不需要特别的加锁语法，我们只需要使用 synchronized 修饰，虚拟机就会根据是否开启偏向锁等条件，自动帮助你实现加锁。如：

假设 Thread-0 想要对 Object 对象上锁：

a. 首次加锁

判断锁对象是否是匿名偏向状态。

如果是，Thread - 0 使用 CAS （Compare and Swap）尝试将 线程ID 赋值给 Object的MarkWord。由于Object的 线程ID 还未被使用（对象创建过后，若为匿名偏向状态，线程ID 字段的初始值为0），赋值成功。

如果线程ID已被占用，而且不是不是Thread -0 的线程ID，说明该锁已经偏向别的线程，加锁失败。

此时 Thread-0 线程首次给 Object 对象加了锁，Object 对象的MarkWord中的 线程ID 就会指向 Thread - 0，

需要注意的是这里所说的 线程ID 是操作系统赋予的唯一标识，并不是 Java 中 Thread.getId()获取到的ID。

b. 再次加锁（锁重入）

synchronized修饰的是可重入锁，如果在同一线程中，偏向锁对象是允许锁的重入的。不过偏向锁的重入很简单，只需要判断锁对象的 线程ID 是否是当前线程即可。

Thread - 0 对 Object 首次加锁成功后，后续只需要判断 线程ID 是否还是自己即可，不需要重新 CAS 将 线程ID 更新到 Object 的 MarkWord 中。

偏向锁的重入没有计数器，只要线程ID还是自己，就认为可重入，即认为可以进入临界区。（同一线程中为顺序执行，不会有线程冲突）

假设 Object锁对象 已经被 Thread - 0 占用，此时线程 Thread -1 来竞争锁对象，流程将如下：

如果在第二步发现 Thread-0已经不存在了，将会尝试进行Object偏向锁的重偏向。如果无法重偏向，将会进行锁升级，上述流程将会变为如下：

如果成功重偏向，将与下述的重偏向一致：

偏向锁没有实际意义上的解锁，离开synchronized代码块后，不会对偏向锁对象的 MarkWord 做修改，即偏向锁态的 MarkWord 中的 线程ID 仍然指向已经过时的线程。

偏向锁作为最“轻”的锁，这样设计的好处是：

下次同一线程再次上锁，只需要判断自己是否曾经持有过锁，而不用再通过 CAS 去替换 MarkWord 中的 线程ID 。如此减少了撤销偏向锁的资源消耗，也减少了同一线程重入时候的CAS消耗。

如果对象虽然被多个线程访问，但是没有竞争，此时偏向原线程（如上述例子的Thread -0） 的对象就有了重偏向其他线程（如上述例子的 Thread-1） 的机会。

重偏向条件：JVM会记录撤销偏向锁的次数，一旦撤销次数超过 20，后续该类中的对象都可以重新偏向加锁线程（即将 线程ID 指向新的线程）。后续线程对重偏向的对象加锁，仍为偏向锁。

重偏向的优点：升级为轻量级锁将会增加CPU的负担，如果没有竞争，可以通过重新偏向来进行锁复用的优化。

偏向锁的撤销：

正如重偏向所介绍的，JVM会记录撤销偏向锁的记录，与重偏向不同的是，撤销次数超过 40的时候，整个类的所有对象均变为不可偏向（锁标志位都变为无锁态001)，包括该类中未来新建的对象也是不可偏向。

无锁态的对象认为偏向锁未开启，未来只会升级为轻量级锁，或者重量级锁，而不会再变为偏向锁。

开启偏向功能的对象，在初始化之后，MarkWord 锁标志位是 101，是可偏向状态

没开启偏向功能的对象，在初始化之后，MarkWord 锁标志位是 001。是不可偏向/Normal状态。

当只有一个线程访问偏向锁的时候，仅仅是把线程ID记录到MarkWord中，没有额外的系统消耗。

但是，当有新的线程也需要对该对象上锁，发现该对象已经被别的线程持有偏向锁（观察到MarkWord中有别的线程ID），此时的竞争升级。

系统将会撤销偏向锁，并将锁升级为轻量级锁（自旋锁）。

设置轻量级锁，首先需要在当前线程的栈帧中创建一个Lock Record，通过使用CAS 尝试将 Lock Record与 Object的 MarkWord 互换，从而进行锁的争抢。

栈帧(Stack Frame)是用于支持虚拟机进行方法调用和方法执行的数据结构，是虚拟机运行时数据区的虚拟机栈（VM Stack）的栈元素。

a. 从无锁态加锁为轻量级锁

假设 Thread - 0 要对 Object 上锁，且为轻量级锁的加锁

【判断锁标志位】判断 MarkWord 是否为无锁态（锁标志位为 001 )。

【创建Lock Record】Thread-0在自己的线程栈的栈帧中创建一个 Lock Record；

【配置Lock Record】新建的 Lock Record 中的 记录内容为 当前 Lock Record 的地址，锁对象的引用(Object reference) 为锁对象的内存地址；

【CAS交换LR与MarkWord】通过 CAS 尝试进行将 Lock Record 的内容与锁对象的 MarkWord 做交换。过程如下图：

交换成功即上锁成功，上锁后的情况如下图：

b. 从偏向锁升级为轻量级锁（锁对象不在重偏向状态）

假设 Thread -1要对 Object上锁，Object当前状态为偏向锁态（ MarkWord 锁标志位为 101）

如果锁对象在重偏向状态，第二个线程将会对偏向锁态的对象进行重偏向到自己线程ID的行为，而不会升级为轻量级锁

c. 锁的重入

假设Thread-0已经持有Object的轻量级锁，此时在本线程内又要对其上锁，即锁重入，流程如下：

需要注意的是，轻量级锁的重入也无需计数器，在解锁过程中，遇到 LockRecord 的记录为空，说明是重入的锁，遇到记录不为空，才算真正解锁。

锁重入的流程图如下：

如果遇到锁对象的 MarkWord 的锁标志位为00，说明该锁对象正在被一个线程持有，且为轻量级锁态。

如果持有锁的线程不是自己，则加锁失败，进入锁升级流程（见重量级锁）。示意图如下：

当自旋到一定轮数，或者自旋线程数到达一定数量，该锁对象将会升级为重量级锁态，具体见后面探讨的重量级锁。

退出栈帧的时候，如果Lock Record的记录为null，说明是重入锁，仅仅是弹出栈帧。

如果Lock Record的记录有值，说明本次解锁是真正解锁（接触的不是重入的锁）。

解锁的过程为：

【判断锁标志位】如果 MarkWord 的锁标志位为 00（如果锁标志位为 10，说明在持有过程中，该锁对象升级为了重量级锁）

【如果锁对象是重量级锁】如果 MarkWord的锁标志位为 10，根据 MarkWord 的 ptr_to_monitor 来找到 ObjectMonitor ，并将owner置为null，同时唤醒 EntryList，由操作系统调度唤醒等待队列中的线程；

【如果锁对象仍然是轻量级锁】如果 MarkWord 的锁标志位为 00 ，通过CAS尝试 将Lock Record的 record 的值与Object锁对象的 MarkWord 交换；

【解锁结果】交换完成后锁对象的 MarkWord 的锁标志位变为 001（上锁前为无锁态），或者101（上锁前为偏向锁态）；

【退出栈帧，并删除 Lock Record】线程栈中删除对应的Lock Record。

问：有偏向锁，为什么还需要轻量级锁？

答：偏向锁在撤销的时候会消耗系统资源，在争抢激烈的时候，效率没有轻量级锁高。

问：为什么JVM默认一开始不打开偏向锁？

答：JVM启动过程中会有很多线程争抢，所以默认启动时不打开偏向锁，而是默认等待4s过后才打开偏向锁。

有的教程说：当发生重度竞争时，即1）有线程超过10次自旋， 2）自旋线程数超过了CPU核数的一般。JVM将会把锁升级为重量级锁。

但我们看到JDK8的源码后，并不是这样，它是直接膨胀为重量级锁，但并不是直接阻塞等待，而是会先进行一会儿 自适应自旋。

重量级锁需要内核态的参与, JVM 向操作系统申请ObjectMonitor，这是一个C++对象，需要内核态才能访问。锁对象的 MarkWord 指向 ObjectMonitor 的地址。

ObjectMonitor 的主要结构如下图：

Owner: 指向持有该 ObjectMonitor 的线程。

EntryList: 等待队列，队列中的线程都为 BLOCKED 状态（Java的六种线程状态之一），等待锁。

WaitSet: 存放处于 WAITING 状态（Java的六种线程状态之一）的线程

Recursions: 持有该 ObjectMonitor 的线程的重入次数。

重量级锁拥有等待队列，没有争抢到锁的线程经过自适应自旋后，进入等待队列，变为 BLOCKED 状态，等待被唤醒。再次启动去争取锁的过程将比较耗时。

当线程获取轻量级锁失败，或者持有偏向锁/轻量级锁的线程运行在临界区，遇到obj.wait()或者obj.notify()方法，都进入重量级锁升级状态。重量级加锁流程如下：

第二步，从轻量级锁升级为重量级的图示如下：

第三部，从偏向锁升级为重量级锁的图示如下：

自适应自旋：

根据情况，增加或减少最大次数的自旋。

JDK6之后使用了自适应自旋，如果线程通过自旋获得重量级锁，则下一次再有线程进行自适应自旋来争取该 ObjectMonitor ，可以提高几次的最大自旋次数。

如果线程在最大次数自旋内没有获得重量级锁（没有争抢到 ObjectMonitor 的owner），则下次再有线程通过自适应自旋来争取该 ObjectMonitor，则减少最大自旋，甚至不进行自旋，直接进入 EntryList 而进入 BLOCKED 状态。

唤醒：只是将线程变为 就绪态，可以被 CPU 分配时间片，并不代表立即运行。

问：有轻量级锁，为什么还需要重量级锁？

答：线程自旋占CPU资源，重度竞争的时候，自旋的时间很长，或者自旋的线程很多，CPU花了更多时间在线程切换上。重量级锁通过内核态参与，将没有争抢到锁的线程阻塞，排队等待，减轻了系统资源的消耗。

我们前面说到，Java通过synchronized关键字对类或者对象上锁，在字节码指令中会有monitorenter和monitorexit，在底层代码中，monitorenter首先判断偏向锁是否开启，尝试加偏向锁，在 sharedRuntime.cpp中逻辑为：

在 fast_enter() 中，如果偏向锁上锁失败，将会转为加轻量级锁，进入 synchronizer.cpp#fast_enter我们看到：

申请轻量级锁，进入synchronizer.cpp#slow_enter我们看到：

创建/获取 ObjectMonitor对象的过程就是锁的膨胀过程，看到 synchronizer.cpp#inflate()方法：