| 🔍 开发者资源导航 🔍 |
|---|
| 🏷️ 博客主页： 个人主页 |
| 📚 专栏订阅： JavaEE全栈专栏 |
synchronized优化原理
synchronized即使悲观锁也是乐观锁，拥有自适应性。 jvm内部会统计每个锁的竞争激烈程度，自动识别。
它在运行时主要有三种优化策略。
锁升级
路径：
无锁->偏向锁->自旋锁->重量级锁
如果对于这些概念不清楚可以参考这篇文章->点我
无锁->偏向锁
所谓偏向锁就是进行一个简单的标记，并不是真正的加锁，这个标记非常的轻量，相对于加锁高效的多。
如果到最后没人和它竞争这个锁，那么到最后只需要清除简单的标记。
偏向锁->自旋锁
在偏向锁的情况下遇到了锁竞争，那么他会在其他线程加锁之前对它先进行加自旋锁的操作。
自旋锁->重量级锁
如果这个锁的竞争情况非常激烈，就会对这个锁升级到重量级锁。
在jvm只提供了锁升级，并没有涉及锁降级操作。
锁消除：
编译器优化的一种体现
编译器会判定，当前的这个代码逻辑是否真的需要加锁，如果确实不需要加锁，但是你写了synchronized，就会自动去掉。
这个判定比较保守，只有100%确认这个代码是单线程的时候才会触发，当判断不清楚的时候不会触发，因此不会出现判断逻辑错误导致的线程安全。
锁粗化：
锁的粒度：加锁和解锁之间，包含的代码越多，就认为锁的粒度越粗，如果越少，就认为越细。这里代码指的是实际执行的指令/时间。
如果检测到一连串连续的对同一个对象的加锁和解锁操作（即使没有竞争），JVM 可能会将这些操作合并为一个更大范围的加锁，减少锁的获取和释放次数，从而提高性能。
优化前（细粒度锁，效率低）
synchronized (obj) {// 操作1
}
synchronized (obj) {// 操作2
}
synchronized (obj) {// 操作3
}
优化后（锁粗化，合并为一个锁）
synchronized (obj) { // JVM 可能会合并成一个锁// 操作1// 操作2// 操作3
}
感谢各位的观看Thanks♪(･ω･)ﾉ，如果觉得满意的话留个关注再走吧。
