Java中Synchronized和Lock的使用

http://blog.csdn.net/imzoer/article/details/9457639

Lock的锁定是通过代码实现的，而 synchronized 是在 JVM 层面上实现的

synchronized在锁定时如果方法块抛出异常，JVM 会自动将锁释放掉，不会因为出了异常没有释放锁造成线程死锁。但是 Lock 的话就享受不到 JVM 带来自动的功能，出现异常时必须在 finally 将锁释放掉，否则将会引起死锁。

synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。

在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好，不管用没用过5.0多线程包的程序员都能理解。 

ReentrantLock

ReentrantLock提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。 
Atomic
和上面的类似，不激烈情况下，性能比synchronized略逊，而激烈的时候，也能维持常态。激烈的时候，Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点，就是只能同步一个值，一段代码中只能出现一个Atomic的变量，多于一个同步无效。因为他不能在多个Atomic之间同步。 

Lock的使用参见下面的代码（把lock换成synchronized的效果是一样的）：

[java] view plain copy

1. import java.util.concurrent.TimeUnit;  
2. import java.util.concurrent.locks.Lock;  
3. import java.util.concurrent.locks.ReentrantLock;  
4.   
5. public class Resource3 {  
6.   
7.     private Lock lock = new ReentrantLock();  
8.   
9.     public void f() {  
10.   
11.         // other operations should not be locked...  
12.   
13.         System.out.println(Thread.currentThread().getName()  
14.                 + ":not synchronized in f()");  
15.         lock.lock();  
16.         try {  
17.             for (int i = 0; i < 5; i++) {  
18.                 System.out.println(Thread.currentThread().getName()  
19.                         + ":synchronized in f()");  
20.                 try {  
21.                     TimeUnit.SECONDS.sleep(3);  
22.                 } catch (InterruptedException e) {  
23.                     e.printStackTrace();  
24.                 }  
25.             }  
26.         } finally {  
27.             lock.unlock();  
28.         }  
29.     }  
30.   
31.     public void g() {  
32.   
33.         // other operations should not be locked...  
34.         System.out.println(Thread.currentThread().getName()  
35.                 + ":not synchronized in g()");  
36.         lock.lock();  
37.         try {  
38.             for (int i = 0; i < 5; i++) {  
39.                 System.out.println(Thread.currentThread().getName()  
40.                         + ":synchronized in g()");  
41.                 try {  
42.                     TimeUnit.SECONDS.sleep(3);  
43.                 } catch (InterruptedException e) {  
44.                     e.printStackTrace();  
45.                 }  
46.             }  
47.         } finally {  
48.             lock.unlock();  
49.         }  
50.     }  
51.   
52.     public void h() {  
53.         // other operations should not be locked...  
54.         System.out.println(Thread.currentThread().getName()  
55.                 + ":not synchronized in h()");  
56.         lock.lock();  
57.         try {  
58.             for (int i = 0; i < 5; i++) {  
59.                 System.out.println(Thread.currentThread().getName()  
60.                         + ":synchronized in h()");  
61.                 try {  
62.                     TimeUnit.SECONDS.sleep(3);  
63.                 } catch (InterruptedException e) {  
64.                     e.printStackTrace();  
65.                 }  
66.             }  
67.         } finally {  
68.             lock.unlock();  
69.         }  
70.     }  
71.   
72.     public static void main(String[] args) {  
73.   
74.         final Resource3 rs = new Resource3();  
75.         new Thread() {  
76.             public void run() {  
77.                 rs.f();  
78.             }  
79.         }.start();  
80.         new Thread() {  
81.             public void run() {  
82.                 rs.g();  
83.             }  
84.         }.start();  
85.         rs.h();  
86.     }  
87. } 
    

synrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象 作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为 Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在 HotSpot JVM实现中，锁有个专门的名字：对象监视器。 

1. 线程状态及状态转换

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

Contention List：所有请求锁的线程将被首先放置到该竞争队列

Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List

Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set

OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck

Owner：获得锁的线程称为Owner

!Owner：释放锁的线程

CAS原理

 CAS通过调用JNI的代码实现的。JNI:Java Native Interface为JAVA本地调用，允许java调用其他语言。

而compareAndSwapInt就是借助C来调用CPU底层指令实现的。

而CAS的全称为Compare-And-Set，是一条CPU的原子指令，其作用是让CPU比较后原子地更新某个位置的值，经过调查发现， 其实现方式是基于硬件平台的汇编指令，就是说CAS是靠硬件实现的，JVM只是封装了汇编调用，那些AtomicInteger类便是使用了这些封装后的 接口

ContentionList并不是一个真正的Queue，而只是一个虚拟队列，原因在于ContentionList是由Node及其next指 针逻辑构成，并不存在一个Queue的数据结构。ContentionList是一个后进先出（LIFO）的队列，每次新加入Node时都会在队头进行， 通过CAS改变第一个节点的的指针为新增节点，同时设置新增节点的next指向后续节点，而取得操作则发生在队尾。显然，该结构其实是个Lock- Free的队列。

因为只有Owner线程才能从队尾取元素，也即线程出列操作无争用，当然也就避免了CAS的ABA问题。

那些处于ContetionList、EntryList、WaitSet中的线程均处于阻塞状态，阻塞操作由操作系统完成（在Linxu下通 过pthread_mutex_lock函数）。线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响 锁的性能

缓解上述问题的办法便是自旋，其原理是：当发生争用时，若Owner线程能在很短的时间内释放锁，则那些正在争用线程可以稍微等一等（自旋）， 在Owner线程释放锁后，争用线程可能会立即得到锁，从而避免了系统阻塞。但Owner运行的时间可能会超出了临界值，争用线程自旋一段时间后还是无法 获得锁，这时争用线程则会停止自旋进入阻塞状态（后退）。基本思路就是自旋，不成功再阻塞，尽量降低阻塞的可能性，这对那些执行时间很短的代码块来说有非 常重要的性能提高。自旋锁有个更贴切的名字：自旋-指数后退锁，也即复合锁。很显然，自旋在多处理器上才有意义

在JVM1.6中引入了偏向锁，偏向锁主要解决无竞争下的锁性能问题，首先我们看下无竞争下锁存在什么问题：

现在几乎所有的锁都是可重入的，也即已经获得锁的线程可以多次锁住/解锁监视对象，按照之前的HotSpot设计，每次加锁/解锁都会涉及到一些CAS操 作（比如对等待队列的CAS操作），CAS操作会延迟本地调用，因此偏向锁的想法是一旦线程第一次获得了监视对象，之后让监视对象“偏向”这个 线程，之后的多次调用则可以避免CAS操作，说白了就是置个变量，如果发现为true则无需再走各种加锁/解锁流程。但还有很多概念需要解释、很多引入的 问题需要解决：