synchronized和LOCK的实现---Java之锁研究.docVIP

Lock和synchronized JDK1.5以后，在锁机制方面引入了新的锁-Lock，在网上的说法都比较笼统，结合网上的信息和我的理解这里做个总结。 java现有的锁机制有两种实现方式，J.DK1.4前是通过synchronized实现，JDK1.5后加入java.util.concurrent.locks包下的各种lock（以下简称Lock） 先说说代码层的区别。 synchronized：在代码里，synchronized类似“面向对象”，修饰类、方法、对象。 Lock：不作为修饰，类似“面向过程”，在方法中需要锁的时候lock，在结束的时候unlock（一般都在finally块里）。 例如代码： Java代码 public void method1() { synchronized(this){//旧锁，无需人工释放 System.out.println(1); } } public void method2() { Lock lock = new ReentrantLock(); lock.lock();//上锁 try{ System.out.println(2); }finally{ lock.unlock();//解锁 } } 其次说说性能。 相关的性能测试网上已经有很多，这里也直接拿来主义，给出结论： 在并发高是，luck性能优势很明显，在低并发时，synchronized也能取得优势。具体的临界范围比较难定论，下面会讨论。 现在来分析它们具体的区别。 锁都是原子性 的，也可以理解为锁是否在使用的标记，并且比较和设置这个标记的操作是原子性的，不同硬件平台上的jdk实现锁的相关方法都是native的（比如 park/unpark），所以不同平台上锁的精确度的等级由这些native的方法决定。所以网上经常可以看见的结论是“Lock比 synchronized有更精确的原子操作”说的也是native方法（不得不感慨C才是硬件王道）。 下面继续讨论怎么由代码层到native的过程。 synchronized -- 对象加锁 所有对象都自动含有单一的锁，JVM负责跟踪对象被加锁的次数。如果一个对象被解锁，其计数变为0。在任务（线程）第一次给对象加锁的时候， 计数变为1。每当这个相同的任务（线程）在此对象上获得锁时，计数会递增。 只有首先获得锁的任务（线程）才能继续获取该对象上的多个锁。每当任务离开时，计数递减，当计数为0的时候，锁被完全释放。synchronized就是基于这个原理，同时synchronized靠某个对象的单一锁技术的次数来判断是否被锁，所以无需（也不能）人工干预锁的获取和释放。 如果结合方法调用时的栈和框架（如果对方法的调用过程不熟悉建议看看/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：释放锁的线程 Lock不同于synchronized面向对象，它基于栈中的框架而不是某个具体对象，所以Lock只需要在栈里设置锁的开始和结束 （lock和unlock）的地方就行了（人工必须标明），不用关心框架大小对象的变化等等。这么做的好处是Lock能提供无条件的、可轮询的、定时的、 可中断的锁获取操作，相对