Lock与synchronized 的区别

1、ReentrantLock 拥有Synchronized相同的并发性和内存语义，此外还多了 锁投票，定时锁等候和中断锁等候

线程A和B都要获取对象O的锁定，假设A获取了对象O锁，B将等待A释放对O的锁定，

如果使用 synchronized ，如果A不释放，B将一直等下去，不能被中断

如果 使用ReentrantLock，如果A不释放，可以使B在等待了足够长的时间以后，中断等待，而干别的事情

ReentrantLock获取锁定与三种方式：

a) lock(), 如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁

b) tryLock(), 如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；

c)tryLock(long timeout,TimeUnit unit)， 如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；

d) lockInterruptibly:如果获取了锁定立即返回，如果没有获取锁定，当前线程处于休眠状态，直到或者锁定，或者当前线程被别的线程中断

2、synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定，但是使用Lock则不行，lock是通过代码实现的，要保证锁定一定会被释放，就必须将unLock()放到finally{}中

3、在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态；

处处都好？

看起来

ReentrantLock

无论在哪方面都比

synchronized

好 —— 所有

synchronized

能做的，它都能做，它拥有与

synchronized

相同的内存和并发性语义，还拥有

synchronized

所没有的特性，在负荷下还拥有更好的性能。那么，我们是不是应当忘记

synchronized

，不再把它当作已经已经得到优化的好主意呢？或者甚至用

ReentrantLock

重写我们现有的

synchronized

代码？实际上，几本
Java 编程方面介绍性的书籍在它们多线程的章节中就采用了这种方法，完全用

Lock

来做示例，只把 synchronized 当作历史。但我觉得这是把好事做得太过了。

还不要抛弃 synchronized

虽然

ReentrantLock

是个非常动人的实现，相对 synchronized 来说，它有一些重要的优势，但是我认为急于把 synchronized 视若敝屣，绝对是个严重的错误。

java.util.concurrent.lock

中的锁定类是用于高级用户和高级情况的工具 。一般来说，除非您对

Lock

的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用
synchronized。

为什么我在一个显然“更好的”实现的使用上主张保守呢？因为对于

java.util.concurrent.lock

中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不能忘记释放锁；在退出

synchronized

块时，JVM 会为您做这件事。您很容易忘记用

finally

块释放锁，这对程序非常有害。您的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因（这也是为什么根本不让初级开发人员使用

Lock

的一个好理由。）

另一个原因是因为，当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。

Lock

类只是普通的类，JVM 不知道具体哪个线程拥有

Lock

对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM
的所有版本中工作。在 JDK 5.0 成为标准（从现在开始可能需要两年）之前，使用

Lock

类将意味着要利用的特性不是每个 JVM 都有的，而且不是每个开发人员都熟悉的。

什么时候选择用 ReentrantLock 代替 synchronized

既然如此，我们什么时候才应该使用

ReentrantLock

呢？答案非常简单 —— 在确实需要一些 synchronized 所没有的特性的时候，比如时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者锁投票。

ReentrantLock

还具有可伸缩性的好处，应当在高度争用的情况下使用它，但是请记住，大多数 synchronized
块几乎从来没有出现过争用，所以可以把高度争用放在一边。我建议用 synchronized 开发，直到确实证明 synchronized 不合适，而不要仅仅是假设如果使用

ReentrantLock

“性能会更好”。请记住，这些是供高级用户使用的高级工具。（而且，真正的高级用户喜欢选择能够找到的最简单工具，直到他们认为简单的工具不适用为止。）。一如既往，首先要把事情做好，然后再考虑是不是有必要做得更快。

Lock

框架是同步的兼容替代品，它提供了

synchronized

没有提供的许多特性，它的实现在争用下提供了更好的性能。但是，这些明显存在的好处，还不足以成为用

ReentrantLock

代替

synchronized

的理由。相反，应当根据您是否 需要

ReentrantLock

的能力来作出选择。大多数情况下，您不应当选择它
—— synchronized 工作得很好，可以在所有 JVM 上工作，更多的开发人员了解它，而且不太容易出错。只有在真正需要

Lock

的时候才用它。在这些情况下，您会很高兴拥有这款工具。

各种同步方法性能比较（synchronized,ReentrantLock,Atomic）参考/article/4036239.html