在前面章节中, 提到了多线程中的锁策略, 那么我们 Java 中的锁 synchronized 背后都采取了哪些锁策略呢? 又是如何进行工作的呢? 本节我们就来谈一谈.
关注收藏, 开始学习吧🧐
在 Java 中, synchronized 具有以下特性(这里以 JDK 1.8 为例):
JVM 将 synchronized 锁分为 无锁, 偏向锁, 轻量级锁, 重量级锁 状态. 会根据情况, 进行依次升级.

第一个尝试加锁的线程, 优先进入偏向锁状态.
随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁). 此处的轻量级锁就是通过 CAS(Compare And Swap) 来实现. CAS 就是字面意思比较并交换, 之后会有章节来讲 CAS 是什么.
自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源. 但此处的自旋并不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了. 就会升级为重量级锁, 也就是所谓的 “自适应”.
如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁. 此处的重量级锁就是指用到内核提供的 mutex .
有些应用程序的代码中, 用到了 synchronized, 但其实没有在多线程环境下. (例如 StringBuffer)
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");
此时每个 append 的调用都会涉及加锁和解锁. 但如果只是在单线程中执行这个代码, 那么这些加锁解锁操作是没有必要的, 白白浪费了一些资源开销.
而 JVM + 编译器, 会智能的判定, 当前的代码, 是否有必要进行加锁. 在其认为没有必要加锁的情况下, 程序员写了加锁, 就会在编译时把加锁操作自动删除掉. 当然, 在进行优化时, 是会保证优化前后逻辑是一致的.
一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.

关于锁的粒度
在加锁操作中包含的要执行的代码越多, 我们就认为锁的粒度越大.

实际开发过程中, 使用细粒度锁, 是期望释放锁的时候其他线程能使用锁.
但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释放锁.
✨ 本文主要讲解了 Java 中 synchronized 锁的一些原理, 是如何进行加锁的, 加锁工程又是怎样的, 以及一些内部的优化操作.
✨ 想了解更多的多线程知识, 可以收藏一下本人的多线程学习专栏, 里面会持续更新本人的学习记录, 跟随我一起不断学习.
✨ 感谢你们的耐心阅读, 博主本人也是一名学生, 也还有需要很多学习的东西. 写这篇文章是以本人所学内容为基础, 日后也会不断更新自己的学习记录, 我们一起努力进步, 变得优秀, 小小菜鸟, 也能有大大梦想, 关注我, 一起学习.
再次感谢你们的阅读, 你们的鼓励是我创作的最大动力!!!!!