Synchronized
synchronized 可以用来修饰
- 方法
- 静态方法
- 对象
但其实本质就是 锁对象，修饰方法时锁 this，修饰静态方法时锁 class，当一个线程获取了一个对象的锁，那么后到的线程都需要等待锁被释放
void synchronized syn() {...}
如上代码其实等同于如下代码
void syn() {
synchronized(this) {
// ...
}
}
对象锁的状态大致分为四种，锁随着竞争激烈应当逐步升级，但不允许回退
- 无锁
- 偏向锁
- 轻量级锁
- 重量级锁
我们开始重点讨论 synchronized 中锁的实现以及加锁策略之前，需要明白以下概念，在 Java 对象头里的有一个字段叫 Mark Word，其中存储了对象的 HashCode，分代年龄和 锁信息，而锁信息就代表着对象加的是一把什么锁
互斥锁
每个对象拥有一个属于自己的宝贝 - monitor，它就是一把 互斥锁，占有锁时 排斥任何人
monitor 十分重量级，每个对象诞生时，monitor 会被初始化为 0
monitor 是一种可重入的，重量级的互斥锁，之所以称之为 重量级，因为其基于监视器 monitor，而 monitor 本质又依赖于底层操作系统 Mutex Lock，线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作,线程之间的切换成本非常高，应此， monitor 应当成为同步的最后一种手段
获取与释放
对应的虚拟机指令分别为 monitorenter 和 monitorexit
- monitorenter : 尝试获取该对象的锁
- monitorexit : 释放该对象锁
如果我们有一个线程试图占用对象，占用后进行一定操作 some process，之后便结束占用，那么虚拟机指令是如此执行的
// before monitorenter ...
monitorenter
// try own lock of object successfully and do something ...
monitorexit
// after monitorexit ...
线程尝试获取一把互斥锁时，需要经过以下步骤
- 若 monitor = 0 ，线程获得一把互斥锁，并且 monitor++
- 若 线程已拥有互斥锁，仍然 monitor++
- 若 monitor != 0 并且 线程未拥有锁，挂起线程，等待锁被释放
线程释放一把互斥锁时，需要经过以下步骤
- monitorexit 后 monitor--
- monitor = 0 后，唤醒等待线程，通知锁已经被释放
自适应自旋锁
线程的阻塞、挂起和唤醒非常损耗性能，耗时比同步代码更长的情况很可能出现，如果同步代码执行本来就比较短，那为何要进行线程切换呢
自旋锁就是为解决这个问题而出现的，当线程尝试获取锁失败时，线程会自旋一段时间后，再尝试获取锁，如果失败那再挂起
自旋过程中，可以理解为等待锁被释放，自旋意思就是做其他事情等待锁被释放，你可以坐着，躺着或干啥都行
自旋性能的关键在于 自旋时长 如何决定，JVM 中采用的是一种 自适应 策略，即通过观察以往自旋时间，若通过该自旋时间后线程获取锁成功，那么下一次自旋这么久也很有可能成功，反着则反，若一直失败，则直接取消自旋会更加划算
锁撤销
当虚拟机检测到，同步的地方并没有同步价值时，编译时会撤销该锁，如下面代码块，则完全不需要同步，String 是不可变对象，完全不可能被修改
public synchronized void print(String s) {
System.out.println(s);
}
锁粗化
我们平时写代码一般要求将锁细化，即只讲锁加在需要同步的地方，然后锁的获取与释放，像刚才提到的互斥锁，是非常耗性能的，因此 当可优化的多段锁出现时，会粗化该锁
public String plus(String s1, String s2, String s3) {
return s1 + s2 + s3;
}
如上述语句可能并发现不了什么不得了的事情，但字符串的拼接是挺费性能的，应当使用 StringBuilder 或者 StringBuffer，虚拟机则如下优化
public String plus(String s1, String s2, String s3) {
StringBuffer buffer = new StringBuffer();
buffer.append(s1);
buffer.append(s2);
buffer.append(s3);
return buffer.toString();
}
StringBuffer 是同步的，所以拼接时会上三把锁，然而一把锁的性能会更好
轻量级锁
使用重量级互斥锁时，我们应当考虑一个问题，一把互斥锁 并不是每时都在被多线程竞争，在不被竞争时，排斥锁的线程切换，就显得没那么必要了，这就是一个优化的点，所以就引入了轻量级锁
在决定使用底层操作系统的 monitor 之前，应当先考虑 轻量级锁，它不使用线程切换，但能达到同步目的
获取与释放
线程尝试获取一把轻量级锁时，需要经过以下步骤
- 若 Mark Word 无锁，则为当前栈帧开辟出一块 Lock Record 内存，并拷贝一份对象 Mark Word 信息
- 尝试将 Mark Word 指向 Lock Record （CAS）
- 若成功，线程获得一把轻量级锁，并将 Lock Record 指向 Mark Word
- 若失败
- 若 Mark Word 指向 Lock Record，说明已经拥有锁
- 若 未指向，说明存在多线程竞争，并将 Mark Word 的锁状态 由轻量级锁膨胀为重量级锁
线程释放一把轻量级锁时，需要经过以下步骤
- 尝试将 Lock Record 替换 Mark Word （CAS）
- 若成功，正常释放
- 若失败，说明在拥有锁的过程中，锁已经膨胀为重量级锁，则唤醒等待线程，通知锁已经被释放
在无竞争条件下，轻量级锁无需进行线程切换，只需要锁获取和释放时的两次 CAS 操作
偏向锁
使用轻量级锁时，我们应当考虑一个问题，CAS 是很消耗 CPU 的，一个对象只被一个线程访问时，不存在轻量级锁竞争，那么轻量级锁的两次 CAS 操作和内存拷贝，就显得些许多余，所以就引入了偏向锁
偏向锁是指对象偏向某个线程，即在无线程竞争条件下，该对象是属于某个线程的，一旦出现竞争，应当撤销偏向锁 并升级为轻量级锁
获取与撤销
线程尝试获取一把偏向锁时，需要经过以下步骤
- 若 Mark Word 无锁，尝试将 currentThreadId 复制到 Lock Record 与 Mark Word 中 （CAS）
- 若成功，线程获得一把偏向锁
- 若失败，说明存在其他线程竞争偏向锁，并撤销偏向锁
撤销偏向锁时，需等到安全点 SafePoint 再执行撤销
加锁策略
虚拟机的加锁策略，是一层一层升级的，简而言之可以如下总结
- 当竞争对象无锁时，先尝试偏向锁
- 当存在不止一个线程获取偏向锁时，应当尝试轻量级锁
- 当存在多线程竞争一个轻量级锁时，需考虑重量级锁
- 当尝试竞争重量级锁失败时，应先尝试自旋锁再考虑线程切换策略
状态转换
当线程竞争锁时，它们之间的状态转化如上图
- Contention List：竞争队列
- Entry List：有资格成为候选人的竞争队列
- OnDeck：锁候选人
- Owner：锁持有者
- Wait Set：线程等待池
与 synchronized 配套使用的 wait / notify / notifyAll，下面我们来探讨它们是如何实现的
- wait ： 释放锁，进入等待池
- notify ： 从等待池中挑选一名同学再次参与竞争
- notifyAll ： 等待池全部恢复竞争
参考
- 《深入理解Java虚拟机》
- 《Java并发编程实战》
- 《Java并发编程艺术》
