Lock & synchronized

内置锁synchronized

显式锁Lock

 

1.ReentrantLock功能性方面更全面，比如时间锁等候，可中断锁等候，锁投票等，因此更有扩展性。在多个条件变量和高度竞争锁的地方，用ReentrantLock更合适，ReentrantLock还提供了Condition，对线程的等待和唤醒等操作更加灵活，一个ReentrantLock可以有多个Condition实例，所以更有扩展性。

2.ReentrantLock必须在finally中释放锁，否则后果很严重，编码角度来说使用synchronized更加简单，不容易遗漏或者出错。

3.ReentrantLock 的性能比synchronized会好点。

4.ReentrantLock提供了可轮询的锁请求，他可以尝试的去取得锁，如果取得成功则继续处理，取得不成功，可以等下次运行的时候处理，所以不容易产生死锁，而synchronized则一旦进入锁请求要么成功，要么一直阻塞，所以更容易产生死锁。

5、Lock的某些方法可以决定多长时间内尝试获取锁，如果获取不到就抛异常，这样就可以一定程度上减轻死锁的可能性。

如果锁被另一个线程占据了，synchronized只会一直等待，很容易错序死锁 

6、synchronized的话，锁的范围是整个方法或synchronized块部分；而Lock因为是方法调用，可以跨方法，灵活性更大 

7、便于测试，单元测试时，可以模拟Lock，确定是否获得了锁，而synchronized就没办法了

8、ReentrantLock可以实现fair lock和 支持中断处理 

 

Java的锁机制的实现方式：

• JDK1.4前是通过synchronized实现
• JDK1.5后加入java.util.concurrent.locks包下的各种lock（以下简称Lock） 

 

代码层的区别：

• synchronized：在代码里，synchronized类似“面向对象”，修饰类、方法、对象。 
• Lock：不作为修饰，类似“面向过程”，在方法中需要锁的时候lock，在结束的时候unlock（一般都在finally块里）。 

   

性能测试：在并发高是，luck性能优势很明显，在低并发时，synchronized也能取得优势。具体的临界范围比较难定论。 

 

具体的区别：

锁都是原子性的，也可以理解为锁是否在使用的标记，并且比较和设置这个标记的操作是原子性的，不同硬件平台上的jdk实现锁的相关方法都是native的（比如park/unpark），所以不同平台上锁的精确度的等级由这些native的方法决定。

“Lock比synchronized有更精确的原子操作”说的也是native方法。 

 

代码层到native的过程：

• 1、所有对象都自动含有单一的锁，JVM负责跟踪对象被加锁的次数。如果一个对象被解锁，其计数变为0。在任务（线程）第一次给对象加锁的时候，计数变为1。每当这个相同的任务（线程）在此对象上获得锁时，计数会递增。 只有首先获得锁的任务（线程）才能继续获取该对象上的多个锁。每当任务离开时，计数递减，当计数为0的时候，锁被完全释放。synchronized就是基于这个原理，同时synchronized靠某个对象的单一锁技术的次数来判断是否被锁，所以无需（也不能）人工干预锁的获取和释放。如果结合方法调用时的栈和框架（如果对方法的调用过程不熟悉建议看看http://wupuyuan.iteye.com/blog/1157548），不难推测出synchronized原理是基于栈中的某对象来控制一个框架，所以对于synchronized有常用的优化是锁对象不锁方法。实际上synchronized作用于方法时，锁住的是“this”，作用于静态方法/属性时，锁住的是存在于永久带的CLASS，相当于这个CLASS的全局锁，锁作用于一般对象时，锁住的是对应代码块。在HotSpot中JVM实现中，锁有个专门的名字：对象监视器。 

当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程 

• Contention List：所有请求锁的线程将被首先放置到该竞争队列，是个虚拟队列，不是实际的Queue的数据结构。 
• Entry List：EntryList与ContentionList逻辑上同属等待队列，ContentionList会被线程并发访问，为了降低对ContentionList队尾的争用，而建立EntryList。，Contention List中那些有资格成为候选人的线程被移到Entry List 
• Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set 
• OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck 
• Owner：获得锁的线程称为Owner 
• !Owner：释放锁的线程 

• 2、Lock不同于synchronized面向对象，它基于栈中的框架而不是某个具体对象，所以Lock只需要在栈里设置锁的开始和结束（lock和unlock）的地方就行了（人工必须标明），不用关心框架大小对象的变化等等。这么做的好处是Lock能提供无条件的、可轮询的、定时的、可中断的锁获取操作，相对于synchronized来说，synchronized的锁的获取是释放必须在一个模块里，获取和释放的顺序必须相反，而Lock则可以在不同范围内获取释放，并且顺序无关。java.util.concurrent.locks下的锁类很类似，依赖于java.util.concurrent.AbstractQueuedSynchronizer，它们把所有的Lock接口操作都转嫁到Sync类上，这个类继承了AbstractQueuedSynchronizer，它同时还包含子2个类：NonfairSync 和FairSync 从名字上可以看的出是为了实现公平和非公平性。AbstractQueuedSynchronizer中把所有的的请求线程构成一个队列（一样也是虚拟的），具体的实现可以参考http://blog.csdn.net/chen77716/article/details/6641477#，这里我就不复制了。 

• 3、从jdk的源代码来看，Lock和synchronized的源码基本相同，区别主要在维护的同步队列上。再往下深究就到了native方法了。

• 4、线程分阻塞（wait）和非阻塞状态，阻塞状态由操作系统完成，当前一个被“锁”的线程执行完毕后，有可能在后续的线程队列里还没分配出一个获取锁而被“唤醒”的非阻塞线程，即所有线程还都是阻塞状态时，就被系统调度（进入内核的线程是阻塞的），这样会导致内核在用户态和内核态之间来回接换，严重影响锁的性能。在jdk1.6以前主要靠自旋锁来解决，原理是在前一个线程结束后，争用线程可以做一个空循环，继续占有CPU，等待取锁的机会。当然这样做显然也是浪费时间，只是在两种浪费中选取浪费少的……  jdk1.6后引入了偏向锁，当线程第一次获得了监视对象，之后让监视对象“偏向”这个线程，之后的多次调用则可以避免CAS操作，等于是置了一临时变量来记录位置（类似索引比较）。偏向锁性能优于自旋锁。

 

对synchronized 的改进：

它有一些功能性的限制 —— 它无法中断一个正在等候获得锁的线程，也无法通过投票得到锁，如果不想等下去，也就没法得到锁。同步还要求锁的释放只能在与获得锁所在的堆栈帧相同的堆栈帧中进行，多数情况下，这没问题（而且与异常处理交互得很好），但是，确实存在一些非块结构的锁定更合适的情况。

 

还不要抛弃 synchronized：

• java.util.concurrent.lock 中的锁定类是用于高级用户和高级情况的工具 。一般来说，除非您对 Lock 的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用 synchronized。
• 因为对于 java.util.concurrent.lock 中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不能忘记释放锁；在退出 synchronized 块时，JVM 会为您做这件事。您很容易忘记用 finally 块释放锁，这对程序非常有害。您的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因。
• 当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM 的所有版本中工作。在 JDK 5.0 成为标准之前，使用 Lock 类将意味着要利用的特性不是每个 JVM 都有的，而且不是每个开发人员都熟悉的。

 

什么时候选择用ReentrantLock代替synchronized：

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

Lock 框架是同步的兼容替代品，它提供了 synchronized 没有提供的许多特性，它的实现在争用下提供了更好的性能。但是，这些明显存在的好处，还不足以成为用 ReentrantLock 代替 synchronized 的理由。相反，应当根据您是否 需要 ReentrantLock 的能力来作出选择。大多数情况下，您不应当选择它 —— synchronized 工作得很好，可以在所有 JVM 上工作，更多的开发人员了解它，而且不太容易出错。只有在真正需要 Lock 的时候才用它。在这些情况下，您会很高兴拥有这款工具。