Synchronized 底层优化是Java面试常调查的点。简略来说，Synchronzied 选用逐渐晋级的加锁机制来下降加锁本钱，每次加锁失利就晋级竞赛下一级锁，每升高一级，加锁本钱就会进步。
在 Java 中，加锁便是线程用锁目符号载自己的一个符号。当其他线程加锁扫描到锁目标已被其他线程符号，就会加锁失利。不再履行后续临界区的代码。
一、Synchronized锁晋级进程color{blue}{一、Synchronized 锁晋级进程}
Synchronized 首要测验获取倾向锁（Biased lock），倾向锁会把目标头中的线程编号字段指向自己，表示锁目标被该线程符号。假如指向失利，则撤销倾向锁，晋级为轻量级锁（Lightweight Lock）。这时线程运用 CAS 把目标头交换到自己的栈。如 CAS 失利，会进行重试（即自旋 Spin），重试屡次依然失利，晋级到重量级锁（Heavyweight Lock），交给 OS 内核进行终究的同步处理。
二、倾向锁被抛弃color{blue}{二、倾向锁被抛弃}
倾向锁只需要设置目标头的几个字段的值就能完成加锁，“功能很高”。但在 JDK15 中，倾向锁被默认封闭。在 JDK18 中，更被符号为抛弃，并不再允许经过命令行手动敞开。
看起来作用很好的倾向锁，为什么逐渐被打入“冷宫”？OpenJDK 开发团队在 JEP 374 中解说：
曩昔看到的功能提高现在远没有那么显着。许多获益于倾向锁的程序都是较旧的遗留程序，它们运用早期的 Java 调集 API，它们在每次访问时进行同步（例如
Hashtable和Vector）。对于较新的程序，针对单线程场景一般运用 Java 1.2 中引进的非同步调集（例如HashMap和ArrayList），针对多线程场景，则运用 Java 5 引进的功能更高的并发结构。这意味着，假如代码晋级到这些较新的类，比较倾向锁，会有更大的功能提高。此外，围绕线程池队列和作业线程构建的应用程序一般在禁用倾向确定的情况下功能更好。（例如，SPECjbb2015 便是这样规划的，而 SPECjvm98 和 SPECjbb2005 则不是）。
倾向确定的代价是在产生锁争用时需要履行贵重的撤销操作。因而，获益于它的程序只是那些无竞赛同步操作的程序。倾向锁的高效是假定在履行简单的锁检查加上偶尔贵重的撤销本钱，依然低于履行 CAS 指令的本钱。但 HotSpot 现已产生了很大的改变，原子指令本钱的改变也改变了坚持该联系所需的无竞赛操作的数量。
另一个值得注意的方面是，当同步操作上花费的时刻只占程序总作业负载的一小部分时，即使从前的本钱联系成立，程序也不会从倾向锁中取得显着的功能改进。
三、抛弃原因剖析color{blue}{三、抛弃原因剖析}
归纳来看，倾向锁被废除主要有下面的原因：
3.1 可维护性差
JEP 374 中写到：
倾向锁在同步子系统中引进了大量杂乱的代码，而且还会侵入其他 HotSpot 组件
为了实现倾向锁，在 JVM 中引进了大量代码。而且，一个理想的代码库，应该做到“高内聚、低耦合”，但倾向锁的代码和各个模块交叉耦合，相互影响。杂乱的倾向锁实现给 OpenJDK 开发者造成了很大的负担，终究让他们不得不考虑放弃。
3.2 优化作用欠好
OpenJDK 开发者统计到同步操作在程序实践运行中耗费的资源较少，即使倾向锁有一定提高，但对总体功能影响不大。别的，随着 JDK 并发数据结构（ConcurrentHashMap、CopyOnWriteArrayList等）和 CAS 操作的功能提高，倾向锁的作用很有限。
3.3 前景欠好
倾向锁优化作用欠好，而且也没看到未来的优化空间。没有产出，也没有预期的产品很难长期存在。
