Synchronized原理
- 一、基本特点
- 二、加锁工作过程 (锁升级/锁膨胀)
- 2.1 偏向锁
- 2.2 轻量级锁
- 2.3 重量级锁
- 三、锁消除
- 四、锁粗化
- 五、总结
一、基本特点
结合锁策略，我们就可以总结出 Synchronized 具有以下特性(只考虑 JDK 1.8)：
- 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁
- 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁
- 实现轻量级锁的时候大概率用到的自旋锁策略
- 是一种不公平锁
- 是一种可重入锁
- 不是读写锁
二、加锁工作过程 (锁升级/锁膨胀)
JVM将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级！
2.1 偏向锁
第一个尝试加锁的线程，优先进入偏向锁状态。
偏向锁本质上相当于"延迟加锁"，能不加锁就不加锁，尽量来避免不必要的加锁开销~
举个例子：假设男主是一个锁，女主是一个线程。如果只有这一个线程来使用这个锁，那么男主女主即使不领证结婚 (避免了高成本操作)，也可以一直幸福的生活下去。
但是女配出现了，也尝试竞争男主，此时不管领证结婚这个操作成本多高，女主也势必要把这个动作完成了，让女配死心~~
2.2 轻量级锁
随着其他线程进入竞争，偏向锁状态被消除，进入轻量级锁状态 (自适应的自旋锁)。
此处的轻量级锁就是通过 CAS 来实现的：
- 通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
- 如果更新成功, 则认为加锁成功
- 如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU)
自旋操作是一直让 CPU 空转，比较浪费 CPU 资源！
因此此处的自旋不会一直持续进行，而是达到一定的时间/重试次数，就不再自旋了。
也就是所谓的 “自适应”！
2.3 重量级锁
如果竞争进一步激烈，自旋不能快速获取到锁状态，就会膨胀为重量级锁！
此处的重量级锁就是指用到内核提供的 mutex
- 执行加锁操作，先进入内核态
- 在内核态判定当前锁是否已经被占用
- 如果该锁没有占用，则加锁成功，并切换回用户态
- 如果该锁被占用，则加锁失败。此时线程进入锁的等待队列挂起，等待被操作系统唤醒
- 经历了一系列的沧海桑田，这个锁被其他线程释放了，操作系统也想起了这个挂起的线程，于是唤醒这个线程，尝试重新获取锁
三、锁消除
编译器+JVM判断锁是否可消除，如果可以就直接消除。
有些应用程序的代码中，用到了 synchronized，但其实没有在多线程环境下 (例如StringBuffer)
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d")
此时每个append的调用都会涉及加锁和解锁。但如果只是在单线程中执行这个代码，那么这些加锁解锁操作是没有必要的，白白浪费了一些资源开销！
四、锁粗化
锁的粒度有粗细之分，取决于synchronized对应代码块中包含多少代码。包含的代码少，粒度细；包含的代码多，粒度粗。
一段逻辑中如果出现多次加锁解锁，编译器+JVM会自动进行锁的粗化。
实际开发过程中，使用细粒度锁，是期望释放锁的时候其他线程能使用锁。
但是实际上可能并没有其他线程来抢占这个锁。这种情况JVM就会自动把锁粗化，避免频繁申请释放锁带来一些额外的锁竞争。
举个例子：
滑稽老哥当了领导，给下属交代工作任务：
方式一：
打电话，交代任务1，挂电话；
打电话，交代任务2，挂电话；
打电话，交代任务3，挂电话。
方式二：
打电话，交代任务1、任务2、任务3、挂电话。
显然，方式二是更高效的方案~~
注意：
1）得是对同一个对象加锁的才能粗化到一起！
2）锁的粒度也不是越粗就越好！像上述反复加锁的场景变粗了确实还行，但是有的时候锁太粗不利于多线程并发，有悖于写多线程的初衷了~~
五、总结
1）可以看到，synchronized 的策略是比较复杂的，在背后做了很多事情，目的为了让程序猿哪怕啥都不懂，也不至于写出特别慢的程序！(JVM 开发者为了 Java 程序猿操碎了心~~)
2）做出的优化都是在不改变逻辑的前提下进行的！
相关面试题
1）什么是偏向锁？
偏向锁不是真的加锁，而只是在锁的对象头中记录一个标记 (记录该锁所属的线程)，如果没有其他线程参与竞争锁，那么就不会真正执行加锁操作，从而降低程序开销。一旦真的涉及到其他的线程竞争，再取消偏向锁状态，进入轻量级锁状态。
2）synchronized 实现原理是什么？
参考本篇所有内容~~
