ReentrantLock 在加锁和内存上提供的语义与内置锁相同， 此外它还提供了一些其他功能，包括定时的锁等待、可中断的锁等待、公平性， 以及实现非块结构的加锁。ReentrantLock 在性能上优于内置锁， 其中在Java 6 上略有胜出，而在Java 5.0 中则是远远胜出。 哪为啥不放弃synchronized，并在所有的新并发代码中都使用ReentrantLock ? 已经有些作者建议这么做， 将“synchronized” 作为一种“遗留”结构，但这会将好事情变坏。
与显示锁相比，内置锁仍然具有很大的优势。内置锁为许多开发人员所熟悉，并且简洁紧凑，而且在许多现有的程序都已经使用了内置锁 - 如果将这两种机制混合使用，那么不仅容易令人困惑，也容易发生错误。ReentrantLock 的危险性比同步机制要高， 如果忘记在finally 上 调用unlock，那么虽然程序能正常运行，但实际已经埋下了一个定时炸弹，并很有可能伤及其他代码。 仅当内置锁不能满足需求时，才可以考虑使用ReentrantLock。
在一些内置锁无法满足需求的情况下，ReentrantLock 可以作为一种高级工具， 当需要一些高级功能时才应该使用ReentrantLock,这些功能包括：可定时的、可 轮训的与可中断的锁获取操作，公平队列，以及非块结构的锁。否则，还是应该 优先使用Synchronized
在Java5.0 中，内置锁对于ReentrantLock 相比还有一个优点，在线程转储中能够给出在哪些调用帧中获得了哪些锁，并能够检测和识别发生死锁的线程。JVM并不知道哪些线程持有ReentrantLock，因此在调试调用的时候，将起不到帮助作用。Java 6 解决了这个问题，它提供了一个管理和调试的接口，锁可以通过该接口进行注册，从而与ReentrantLocks 相关的加锁信息就能出现在线程转储中，并通过其他的管理接口和调试接口来访问。与Synchronized相比，这些调试消息是一个重要的优势，即便他们大部分都是临时性消息，线程转储中的加锁能给很多程序员带来帮助。ReentrantLock 的非块结构特性仍然意味着，获取锁的操作不能与特定的栈帧关联起来，而内置锁可以。
未来更有可能提升的是Synchronized性能，而不是ReentrantLock的性能。因为Synchronized是JVM的内置属性，他能执行一些优化，例如对线程封闭的锁对象的 锁消除优化 ， 通过增加锁的粒度来消除内置锁的同步， 而如果通过基于类库的锁来实现这些功能，则可能性不大。除非将来需要在Java 5.0 上部署应用程序， 并且该平台上确实需要ReentrantLock包含的可伸缩性，否则就性能方面来说，应该选择Synchroinzed而不是ReentrantLock。
小结
与内置锁相比，显式的Lock 提供了一些扩展功能，在处理锁的不可用性方面有着更高的灵活性，并且对队列行有着更好的控制。但ReentrantLock不能完全替代Synchronized，只有在synchronized无法满足的时候，才使用他。
