Skip to content

Commit e8dd610

Browse files
committed
[docs update]增加偏向锁废弃原因
1 parent 029713f commit e8dd610

File tree

1 file changed

+22
-0
lines changed

1 file changed

+22
-0
lines changed

docs/java/concurrent/java-concurrent-questions-02.md

+22
Original file line numberDiff line numberDiff line change
@@ -573,6 +573,28 @@ public class SynchronizedDemo2 {
573573

574574
`synchronized` 锁升级是一个比较复杂的过程,面试也很少问到,如果你想要详细了解的话,可以看看这篇文章:[浅析 synchronized 锁升级的原理与实现](https://www.cnblogs.com/star95/p/17542850.html)
575575

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+
576598
### ⭐️synchronized 和 volatile 有什么区别?
577599

578600
`synchronized` 关键字和 `volatile` 关键字是两个互补的存在,而不是对立的存在!

0 commit comments

Comments
 (0)