面试官：说一下Synchronized底层实现，锁升级的具体过程？
面试官：说一下Synchronized底层实现，锁升级的具体过程？
这是我去年7，8月份面试的时候被问的一个面试题，说实话被问到这个问题还是很意外的，感觉这个东西没啥用啊，直到后面被问了一波new Object，Integer对象等作为加锁对象行吗？会出现哪些问题？为啥java6后synchronized性能大幅上升？我彻底蒙蔽了。下面详细总结一下
synchronized使用方式
我们知道并发编程会产生各种问题的源头是可见性，原子性，有序性。
而synchronized能同时保证可见性，原子性，有序性。所以我们在解决并发问题的时候经常用synchronized，当然还有很多其他工具，如volatile。但是volatile只能保证可见性，有序性，不能保证原子性，参见我之前的文章
面试官：volatile关键字用过吧？说一下作用和实现吧
synchronized可以用在如下地方
修饰实例方法，对当前实例对象this加锁
修饰静态方法，对当前类的Class对象加锁
修饰代码块，指定加锁对象，对给定对象加锁
修饰实例方法
public class SynchronizedDemo {
public synchronized void methodOne() {
}
}
修饰静态方法
public class SynchronizedDemo {
public static synchronized void methodTwo() {
}
}
修饰代码块
public class SynchronizedDemo {
public void methodThree() {
// 对当前实例对象this加锁
synchronized (this) {
}
}
public void methodFour() {
// 对class对象加锁
synchronized (SynchronizedDemo.class) {
}
}
}
synchronized实现原理
Java对象组成
我们都知道对象是放在堆内存中的，对象大致可以分为三个部分，分别是对象头，实例变量和填充字节
对象头，主要包括两部分1. Mark Word （标记字段），2.Klass Pointer（类型指针）。Klass Point 是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例（即指向方法区类的模版信息）。Mark Word用于存储对象自身的运行时数据
实例变量，存放类的属性数据信息，包括父类的属性信息，这部分内存按4字节对齐
填充数据，由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐
假如有如下的类，a=100这个信息就存储在实例变量中
public class Test {
int a = 100;
}
1
2
3
填充数据主要是为了方便内存管理，如你想要10字节的内存，但是会给你分配16字节的内存，多出来的字节就是填充数据
synchronized不论是修饰方法还是代码块，都是通过持有修饰对象的锁来实现同步，那么synchronized锁对象是存在哪里的呢？答案是存在锁对象的对象头Mark Word，来看一下Mark Word存储了哪些内容？
由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下 (32位虚拟机)：
其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，稍后我们会简要分析。这里我们主要分析一下重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的），省略部分属性
ObjectMonitor() {
_count = 0; //记录数
_recursions = 0; //锁的重入次数
_owner = NULL; //指向持有ObjectMonitor对象的线程
_WaitSet = NULL; //调用wait后，线程会被加入到_WaitSet
_EntryList = NULL ; //等待获取锁的线程，会被加入到该列表
}
结合线程状态解释一下执行过程。(状态装换参考自《深入理解Java虚拟机》)
新建（New），新建后尚未启动的线程
运行（Runable），Runnable包括了操作系统线程状态中的Running和Ready
无限期等待（Waiting），不会被分配CPU执行时间，要等待被其他线程显式的唤醒。例如调用没有设置Timeout参数的Object.wait()方法
限期等待（Timed Waiting），不会被分配CPU执行时间，不过无需等待其他线程显示的唤醒，在一定时间之后会由系统自动唤醒。例如调用Thread.sleep()方法
阻塞（Blocked），线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待获取着一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生，而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态
结束（Terminated）：线程结束执行
对于一个synchronized修饰的方法(代码块)来说：
当多个线程同时访问该方法，那么这些线程会先被放进_EntryList队列，此时线程处于blocked状态
当一个线程获取到了对象的monitor后，那么就可以进入running状态，执行方法，此时，ObjectMonitor对象的/_owner指向当前线程，_count加1表示当前对象锁被一个线程获取
当running状态的线程调用wait()方法，那么当前线程释放monitor对象，进入waiting状态，ObjectMonitor对象的/_owner变为null，_count减1，同时线程进入_WaitSet队列，直到有线程调用notify()方法唤醒该线程，则该线程进入_EntryList队列，竞争到锁再进入_Owner区
如果当前线程执行完毕，那么也释放monitor对象，ObjectMonitor对象的/_owner变为null，_count减1
由此看来，monitor对象存在于每个Java对象的对象头中(存储的是指针)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因
synchronized如何获取monitor对象？
那么synchronized是通过什么方式来获取monitor对象的？
synchronized修饰代码块
public class SyncCodeBlock {
public int count = 0;
public void addOne() {
synchronized (this) {
count++;
}
}
}
javac SyncCodeBlock.java
javap -v SyncCodeBlock.class
1
2
反编译的字节码如下
public void addOne();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter // 进入同步方法
4: aload_0
5: dup
6: getfield #2 // Field count:I
9: iconst_1
10: iadd
11: putfield #2 // Field count:I
14: aload_1
15: monitorexit // 退出同步方法
16: goto 24
19: astore_2
20: aload_1
21: monitorexit // 退出同步方法
22: aload_2
23: athrow
24: return
Exception table:
可以看到进入同步代码块，执行monitorenter指令，退出同步代码块，执行monitorexit指令，可以看到有2个monitorexit指令，第一个是正常退出执行的，第二个是当异常发生时执行的
synchronized修饰方法
public class SyncMethod {
public int count = 0;
public synchronized void addOne() {
count++;
}
}
反编译的字节码如下
public synchronized void addOne();
descriptor: ()V
// 方法标识ACC_PUBLIC代表public修饰，ACC_SYNCHRONIZED指明该方法为同步方法
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
Code:
stack=3, locals=1, args_size=1
0: aload_0
1: dup
2: getfield #2 // Field count:I
5: iconst_1
6: iadd
7: putfield #2 // Field count:I
10: return
LineNumberTable:
我们并没有看到monitorenter和monitorexit指令，那是怎么来实现同步的呢？
可以看到方法被标识为ACC_SYNCHRONIZED，表明这是一个同步方法
锁的升级
在Java早期版本中，synchronized属于重量级锁，效率低下，因为操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。
庆幸的是在jdk1.6之后Java官方对从JVM层面对synchronized较大优化，所以现在的synchronized锁效率也优化得很不错了，Jdk1.6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了偏向锁和轻量级锁，简单介绍一下
jdk1.6之前的synchronized到底有多慢？
我们假设执行下面的代码用的是jdk1.5，来看看会发生什么。
假设doSomeThing执行1000次，才有可能发生一次并发执行。但是每次都需要让操作系统从用户态转换到核心态，太耗时了。
public class RunTest {
public synchronized void doSomeThing() {
}
}
然后Doug Lea看不下去了（你用的并发包就是他写的），写了ReentrantLock类，效率比synchronized快多了，为了理解让大家理解ReentrantLock到底快在哪？我仿造ReentrantLock写一个实现
public class MyLock {
private volatile int state;
// 这里应该用并发安全的容器，这里只是举例
private List<Thread> threadList = new ArrayList<>();
private static final Unsafe unsafe;
private static final long stateOffset;
static {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
unsafe = (Unsafe) field.get(null);
stateOffset = unsafe.objectFieldOffset
(MyLock.class.getDeclaredField("state"));
} catch (Exception ex) { throw new Error(ex); }
}
public void lock() {
while (!compareAndSetState(0, 1)) {
park();
}
}
public void unLock() {
while (compareAndSetState(1, 0)) {
unPark();
}
}
private void park() {
threadList.add(Thread.currentThread());
LockSupport.park(Thread.currentThread());
}
private void unPark() {
if (!threadList.isEmpty()) {
Thread thread = threadList.get(0);
System.out.println(thread.getName());
LockSupport.unpark(thread);
}
}
private boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
}
可以看到在api层面就已经解决并发问题，加锁没有竞争的时候一个cas就搞定了，节省了大量时间
Doug Lea一个类的效率都比synchronized的效率高，估计synchronized的开发人员看了都不好意思了，于是对synchronized进行了一系列改造，即我们常说的锁升级过程。
synchronized锁有四种状态，无锁，偏向锁，轻量级锁，重量级锁，这几个状态会随着竞争状态逐渐升级，锁可以升级但不能降级，但是偏向锁状态可以被重置为无锁状态
偏向锁
为什么要引入偏向锁？
因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。
偏向锁原理和升级过程
当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。
轻量级锁
为什么要引入轻量级锁？
轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。
轻量级锁原理和升级过程
线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；
如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。 自旋锁简单来说就是让线程2在循环中不断CAS
但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。
几种锁的优缺点
用锁的最佳实践
错误的加锁姿势1
synchronized (new Object())
1
每次调用创建的是不同的锁，相当于无锁
错误的加锁姿势2
private Integer count;
synchronized (count)
1
2
String，Boolean在实现了都用了享元模式，即值在一定范围内，对象是同一个。所以看似是用了不同的对象，其实用的是同一个对象。会导致一个锁被多个地方使用
Java常量池详解，秒懂各种对象相等操作
正确的加锁姿势
// 普通对象锁
private final Object lock = new Object();
// 静态对象锁
private static final Object lock = new Object();
1
2
3
4
题外话
ConcurrentHashMap在jdk1.7的时候，实现用的是分段锁，用ReentrantLock来保证并发安全。
而在jdk1.8的时候，抛弃了原有的分段锁，而采用了 CAS + synchronized 来保证并发安全性，也可以说明synchronized的的效率现在确实很高了。
Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的
与synchronized相比，重入锁有着显式的操作过程，开发人员必须手动的指定何时加锁（调用lock方法），何时释放锁（调用unlock方法）。因此，重入锁对逻辑的控制性要好于synchronized。
重入锁，顾名思义，对于同一个线程，这种锁是可以反复进入的。如果一个线程多次获得锁，那么在释放锁的时候，也必须释放相同的次数。
一、synchronized原理
synchronized用的锁是存在java对象头里的
JVM基于进入和退出Monitor对象来实现方法同步和代码块同步。
synchronized和lock的区别(底层实现)
从使用的角度看 synchronized 和 lock 的区别
起初 java 中只有 synchronized 这一种对程序加锁的方式，在 java SE5 之后加入了 Lock 接口（以及相关实现类）用来实现锁的功能，它提供了与 synchronized 关键字类似的同步功能，只是在使用时需要显式的获取和释放锁。
Object lock = new Object();
synchronized(lock) { //加锁
//... 逻辑 ...
} //解锁
Lock lock = new ReentrantLock();
lock.lock(); //加锁
try {
//... 逻辑 ...
} finally {
lock.unlock(); //解锁
}
可以说 synchronized 是一种更简单的同步化管理，而使用 lock 可以对同步程序有更自由的控制，实现更复杂的功能，比方说有这样一个场景：先获取锁 A ，再获取锁 B，当获取锁 B 后，释放锁 A 同时获取锁 C，获取锁 C 后，再释放 B 同时获取 D。这种场景用 synchronized 是无法实现的，但是用 lock 可以实现。
从实现的角度看 synchronized 和 lock 的区别
虽然 synchronized 与 lock 的功能都是对程序加锁和解锁，但是它们的实现方式完全不同，我觉得这可能与历史原因有关，因为刚开始 java 是没有 lock 的，如果它们是同时被发明的话，我猜可能 lock 就是 synchronized 的底层实现了（大胆胡说）。
既然都是锁，那锁住的是什么呢？是如何标记的呢？
synchronized
synchronized 锁住的是普通对象或类对象（http://www.importnew.com/21866.html 不了解可以先看这篇），当一个对象被锁时，就在它的对象头中进行一个标记，在 jvm 堆中的每个对象都有对象头，就像 http 的头部一样，存着一些通用的必要信息，其中名为 MarkWord 的一部分信息就是用来记录锁相关信息的，当你对一个对象加锁解锁时，就会对下图中锁状态这个标准位进行修改：
lock
lock 锁住的是 Lock 对象，当调用它的 lock 方法时，会将 Lock 类中的一个标志位 state 加 1（state 其实是 AbstractQueuedSynchronizer 这个类中的一个变量，它是 Lock 中一个内部类的父类），释放锁时是将 state 减 1（加 1 减 1 这样的操作是为了实现可重入），想要详细了解其中的细节可以看一看 ReentrantLock 这个类的源码。
当它们于到竞争时会如何处理？
synchronized
在 java 1.6 之前 synchronized 一直是重量级锁，无法获取到锁就直接挂起线程，但是在 1.6 之后为了优化 synchronized 的性能给它的锁加入了四种状态，无锁状态 -> 偏向锁 -> 轻量级锁 -> 重量级锁（在 MarkWord 储存状态中就可以看到）
因为 jvm 的开发者发现在大部分情况下，锁都在被同一个线程反复加锁、解锁，所以就在一开始先假定锁一直都在被同一线程使用，将锁设置为偏向某一线程，再次获取时就不需要加解锁了。但是如果在设置 MarkWord 偏向锁线程ID时失败（底层用的是CAS操作，如果设置失败），那就将锁升级为轻量级锁，轻量级锁是假定在一个线程占有锁时，不会有其他线程来竞争，或即使来竞争也不需要等太长时间，所以当某一线程要获取的锁处于轻量级加锁状态时，会一直自旋等待（忙等待）而不是挂起线程，但是当等待时间超过一定时间后，就会将锁再次升级为重量级锁，并将当前线程阻塞挂起，当在有线程请求锁时，如果获取不到就直接阻塞挂起。
synchronized总结：
| 锁状态 | 假定情况 | 竞争处理策略 |
|---|---|---|
| 偏向锁 | 假定获取锁的一直都是同一个线程 | 升级为轻量锁 |
| 轻量级锁 | 假定锁被占用时不会有其他线程获取 | 自旋等待，超时升级 |
| 重量级锁 | 最坏情况，经常发生竞争 | 直接将要获取锁的线程挂起 |
ReentrantLock
ReentrantLock 在遇到竞争时有公平和非公平两种处理模式，在创建对象时可以指定。当线程要获取锁失败时，会将线程添加到一个由链表实现的队列尾部，依次选取队列头部的线程运行。非公平模式下，在还未将新来的线程添加到尾部时，如果当前没有正在运行的线程，就直接插队运行新线程了。而在公平模式下不允许这种插队发生。
对公平非公平的源码分析可以看https://blog.csdn.net/m47838704/article/details/80013056
最后的比较总结
| . | synchronized | lock |
|---|---|---|
| 使用策略 | 简单易用 | 需要注意的更多，也可以实现更复杂的功能 |
| 加锁方式 | 将普通对象与类对象做为锁 | 专门的 Lock 类对象作为锁 |
| 竞争解决 | 一系列的锁膨胀策略 | 加入排队队列 |
| 公平性 | 非公平 | 公平/非公平 两种模式可选 |
| 可重入性 | 可重入 | 可重入 |
欢迎关注
参考博客
好文
[0]https://blog.csdn.net/tongdanping/article/details/79647337
[1]https://blog.csdn.net/javazejian/article/details/72828483
[2]https://www.cnblogs.com/grow001/p/12232708.html?utm_source=gold_browser_extension
[3]https://blog.csdn.net/chenssy/article/details/54883355
lock接口方法简介
[4]https://zhuanlan.zhihu.com/p/38264728
condition的使用
[5]https://www.cnblogs.com/xrq730/p/4855155.html
线程状态
[6]https://blog.csdn.net/xiaosheng900523/article/details/82964768
————————————————
版权声明：本文为CSDN博主「Java识堂」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zzti_erlie/article/details/103997713
