File tree 1 file changed +22
-0
lines changed
1 file changed +22
-0
lines changed Original file line number Diff line number Diff line change @@ -573,6 +573,28 @@ public class SynchronizedDemo2 {
573
573
574
574
` synchronized ` 锁升级是一个比较复杂的过程,面试也很少问到,如果你想要详细了解的话,可以看看这篇文章:[ 浅析 synchronized 锁升级的原理与实现] ( https://www.cnblogs.com/star95/p/17542850.html ) 。
575
575
576
+ ### synchronized 的偏向锁为什么被废弃了?
577
+
578
+ Open JDK 官方声明:[ JEP 374: Deprecate and Disable Biased Locking] ( https://openjdk.org/jeps/374 )
579
+
580
+ 在官方声明中,主要原因有两个方面:
581
+
582
+ - ** 性能收益不明显:**
583
+
584
+ 偏向锁是 HotSpot 虚拟机的一项优化技术,可以提升单线程对同步代码块的访问性能。
585
+
586
+ 受益于偏向锁的应用程序通常使用了早期的 Java 集合 API,例如 HashTable、Vector,在这些集合类中通过 synchronized 来控制同步,这样在单线程频繁访问时,通过偏向锁会减少同步开销。
587
+
588
+ 随着 JDK 的发展,出现了 ConcurrentHashMap 高性能的集合类,在集合类内部进行了许多性能优化,此时偏向锁带来的性能收益就不明显了。
589
+
590
+ 偏向锁仅仅在单线程访问同步代码块的场景中可以获得性能收益。
591
+
592
+ 如果存在多线程竞争,就需要 ** 撤销偏向锁** ,这个操作的性能开销是比较昂贵的。偏向锁的撤销需要等待进入到全局安全点(safe point),该状态下所有线程都是暂停的,此时去检查线程状态并进行偏向锁的撤销。
593
+
594
+ - ** JVM 内部代码维护成本太高:**
595
+
596
+ 偏向锁将许多复杂代码引入到同步子系统,并且对其他的 HotSpot 组件也具有侵入性。这种复杂性为理解代码、系统重构带来了困难,因此, OpenJDK 官方希望禁用、废弃并删除偏向锁。
597
+
576
598
### ⭐️synchronized 和 volatile 有什么区别?
577
599
578
600
` synchronized ` 关键字和 ` volatile ` 关键字是两个互补的存在,而不是对立的存在!
You can’t perform that action at this time.
0 commit comments