本文共 802 字，大约阅读时间需要 2 分钟。

ReentrantLock在加锁和内存上提供的语义与内置锁synchronized相同，此外它还提供了一些其他功能，比如定时的锁等待，可中断的锁等待，公平性，以及实现非块结构的加锁。

ReentrantLock在性能上似乎优于内置锁，其中在Java6中略有胜出，而在Java5.0则是远远胜出。那么为什么不直接弃用synchronized，并在所有的并发代码中都是用ReentrantLock？

与显示锁ReentrantLock相比，内置锁synchronized仍然具有很大的优势。

• 内置锁为许多开发人员使用，并且简单，如果这两种机制混合使用，那么不仅仅容易令人困惑，也容易发生错误。
• ReentrantLock的危险性比较高，如果忘记了在finally块中调用unlock，那么虽然代码表面上能正常运行，但实际上已经埋下了一颗定时炸弹。
• 仅当内置锁不能满足需求时，才可以实际使用ReentrantLock。

当需要一些高级功能，比如：可定时的，可轮询的与可中断的锁获取操作，公平队列，以及非块结构锁等，那么应该使用ReentrantLock。否则，还是应该使用synchronized。

在Java5.0中，内置锁与ReentrantLock还有一个优势：在线程转储中能给出与哪些调用帧中获得了哪些锁，并能够检测和识别发生死锁的线程。JVM并不知道哪些线程持有ReentrantLock，因此在调试使用ReentrantLock的线程的问题时，将起不到帮助的作用。不过在Java6中，ReentrantLock解决了这个问题。

未来更可能会提升synchronized而不是ReentrantLock的性能。因为synchronized是JVM的内置属性，它能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果通过基于类库的锁来实现这些功能，则可能性不大。

转载地址：https://blog.csdn.net/hxcaifly/article/details/88379737 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！