一、基本特点

结合锁策略，我们就可以总结出 Synchronized 具有以下特性(只考虑 JDK 1.8)：

二、加锁工作过程 (锁升级/锁膨胀)

JVM将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级！

第一个尝试加锁的线程，优先进入偏向锁状态。

偏向锁本质上相当于”延迟加锁”，能不加锁就不加锁，尽量来避免不必要的加锁开销~

举个例子：假设男主是一个锁，女主是一个线程。如果只有这一个线程来使用这个锁，那么男主女主即使不领证结婚 (避免了高成本操作)，也可以一直幸福的生活下去。
但是女配出现了，也尝试竞争男主，此时不管领证结婚这个操作成本多高，女主也势必要把这个动作完成了，让女配死心~~

随着其他线程进入竞争，偏向锁状态被消除，进入轻量级锁状态 (自适应的自旋锁)。
此处的轻量级锁就是通过 CAS 来实现的：

自旋操作是一直让 CPU 空转，比较浪费 CPU 资源！
因此此处的自旋不会一直持续进行，而是达到一定的时间/重试次数，就不再自旋了。
也就是所谓的 “自适应”！

如果竞争进一步激烈，自旋不能快速获取到锁状态，就会膨胀为重量级锁！
此处的重量级锁就是指用到内核提供的 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 实现原理是什么？

参考本篇所有内容~~

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/118579.html