ava 8新特性探究-StampedLock將是解決同步問題的新寵
synchronized
在java5之前，實現同步主要是使用synchronized。它是Java語言的關鍵字，當它用來修飾一個方法或者一個代碼塊的時候，能夠保證在同一時刻最多只有一個線程執行該段代碼。
有四種不同的同步塊：
-
實例方法
-
靜態方法
-
實例方法中的同步塊
-
靜態方法中的同步塊
大家對此應該不陌生，所以不多講了，以下是代碼示例
|
1 2 3 |
synchronized(this) // do operation }
|
小結：在多線程并發編程中Synchronized一直是元老級角色，很多人都會稱呼它為重量級鎖，但是隨著Java SE1.6對Synchronized進行了各種優化之后，性能上也有所提升。
Lock
它是Java 5在java.util.concurrent.locks新增的一個API。
Lock是一個接口，核心方法是lock()，unlock()，tryLock()，實現類有ReentrantLock, ReentrantReadWriteLock.ReadLock, ReentrantReadWriteLock.WriteLock；
ReentrantReadWriteLock, ReentrantLock 和synchronized鎖都有相同的內存語義。
與synchronized不同的是，Lock完全用Java寫成，在java這個層面是無關JVM實現的。Lock提供更靈活的鎖機制，很多 synchronized 沒有提供的許多特性，比如鎖投票，定時鎖等候和中斷鎖等候，但因為lock是通過代碼實現的，要保證鎖定一定會被釋放，就必須將unLock()放到 finally{}中
下面是Lock的一個代碼示例
|
1 2 3 4 5 6 |
rwlock.writeLock().lock(); try { // do operation } finally { rwlock.writeLock().unlock(); }
|
小結：比synchronized更靈活、更具可伸縮性的鎖定機制，但不管怎么說還是synchronized代碼要更容易書寫些
StampedLock
它是java8在java.util.concurrent.locks新增的一個API。
ReentrantReadWriteLock 在沒有任何讀寫鎖時，才可以取得寫入鎖，這可用于實現了悲觀讀?。≒essimistic Reading），即如果執行中進行讀取時，經常可能有另一執行要寫入的需求，為了保持同步，ReentrantReadWriteLock 的讀取鎖定就可派上用場。
然而，如果讀取執行情況很多，寫入很少的情況下，使用 ReentrantReadWriteLock 可能會使寫入線程遭遇饑餓（Starvation）問題，也就是寫入線程吃吃無法競爭到鎖定而一直處于等待狀態。
StampedLock控制鎖有三種模式（寫，讀，樂觀讀），一個StampedLock狀態是由版本和模式兩個部分組成，鎖獲取方法返回一個數字作為票據stamp，它用相應的鎖狀態表示并控制訪問，數字0表示沒有寫鎖被授權訪問。在讀鎖上分為悲觀鎖和樂觀鎖。
所謂的樂觀讀模式，也就是若讀的操作很多，寫的操作很少的情況下，你可以樂觀地認為，寫入與讀取同時發生幾率很少，因此不悲觀地使用完全的讀取鎖 定，程序可以查看讀取資料之后，是否遭到寫入執行的變更，再采取后續的措施（重新讀取變更信息，或者拋出異常） ，這一個小小改進，可大幅度提高程序的吞吐量！！
下面是java doc提供的StampedLock一個例子
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
class Point { private double x, y; private final StampedLock sl = new StampedLock(); void move(double deltaX, double deltaY) { // an exclusively locked method long stamp = sl.writeLock(); try { x += deltaX; y += deltaY; } finally { sl.unlockWrite(stamp); } } //下面看看樂觀讀鎖案例 double distanceFromOrigin() { // A read-only method long stamp = sl.tryOptimisticRead(); //獲得一個樂觀讀鎖 double currentX = x, currentY = y; //將兩個字段讀入本地局部變量 if (!sl.validate(stamp)) { //檢查發出樂觀讀鎖后同時是否有其他寫鎖發生？ stamp = sl.readLock(); //如果沒有，我們再次獲得一個讀悲觀鎖 try { currentX = x; // 將兩個字段讀入本地局部變量 currentY = y; // 將兩個字段讀入本地局部變量 } finally { sl.unlockRead(stamp); } } return Math.sqrt(currentX * currentX + currentY * currentY); } //下面是悲觀讀鎖案例 void moveIfAtOrigin(double newX, double newY) { // upgrade // Could instead start with optimistic, not read mode long stamp = sl.readLock(); try { while (x == 0.0 && y == 0.0) { //循環，檢查當前狀態是否符合 long ws = sl.tryConvertToWriteLock(stamp); //將讀鎖轉為寫鎖 if (ws != 0L) { //這是確認轉為寫鎖是否成功 stamp = ws; //如果成功 替換票據 x = newX; //進行狀態改變 y = newY; //進行狀態改變 break; } else { //如果不能成功轉換為寫鎖 sl.unlockRead(stamp); //我們顯式釋放讀鎖 stamp = sl.writeLock(); //顯式直接進行寫鎖 然后再通過循環再試 } } } finally { sl.unlock(stamp); //釋放讀鎖或寫鎖 } } }
|
小結：
StampedLock要比ReentrantReadWriteLock更加廉價，也就是消耗比較小。
StampedLock與ReadWriteLock性能對比
下圖是和ReadWritLock相比，在一個線程情況下，是讀速度其4倍左右，寫是1倍。
下圖是六個線程情況下，讀性能是其幾十倍，寫性能也是近10倍左右：
下圖是吞吐量提高：
總結
1、synchronized是在JVM層面上實現的，不但可以通過一些監控工具監控synchronized的鎖定，而且在代碼執行時出現異常，JVM會自動釋放鎖定；
2、ReentrantLock、ReentrantReadWriteLock,、StampedLock都是對象層面的鎖定，要保證鎖定一定會被釋放，就必須將unLock()放到finally{}中；
3、StampedLock 對吞吐量有巨大的改進，特別是在讀線程越來越多的場景下；
4、StampedLock有一個復雜的API，對于加鎖操作，很容易誤用其他方法;
5、當只有少量競爭者的時候，synchronized是一個很好的通用的鎖實現;
6、當線程增長能夠預估，ReentrantLock是一個很好的通用的鎖實現;
本文鏈接：http://my.oschina.net/benhaile/blog/264383
