Java多執行緒7 Lock&Condition實現執行緒同步通訊
1 synchronized的缺陷
synchronized是java中的一個關鍵字，也就是說是Java語言內建的特性。那麼為什麼會出現Lock呢？
在上面一篇文章中，我們瞭解到如果一個程式碼塊被synchronized修飾了，當一個執行緒獲取了對應的鎖，並執行該程式碼塊時，其他執行緒便只能一直等待，等待獲取鎖的執行緒釋放鎖，而這裡獲取鎖的執行緒釋放鎖只會有兩種情況：
1）獲取鎖的執行緒執行完了該程式碼塊，然後執行緒釋放對鎖的佔有；
2）執行緒執行發生異常，此時JVM會讓執行緒自動釋放鎖。
那麼如果這個獲取鎖的執行緒由於要等待IO或者其他原因（比如呼叫sleep方法）被阻塞了，但是又沒有釋放鎖，其他執行緒便只能乾巴巴地等待，試想一下，這多麼影響程式執行效率。
因此就需要有一種機制可以不讓等待的執行緒一直無期限地等待下去（比如只等待一定的時間或者能夠響應中斷），通過Lock就可以辦到。
再舉個例子：當有多個執行緒讀寫檔案時，讀操作和寫操作會發生衝突現象，寫操作和寫操作會發生衝突現象，但是讀操作和讀操作不會發生衝突現象。
但是採用synchronized關鍵字來實現同步的話，就會導致一個問題：
如果多個執行緒都只是進行讀操作，所以當一個執行緒在進行讀操作時，其他執行緒只能等待無法進行讀操作。
因此就需要一種機制來使得多個執行緒都只是進行讀操作時，執行緒之間不會發生衝突，通過Lock就可以辦到。
另外，通過Lock可以知道執行緒有沒有成功獲取到鎖。這個是synchronized無法辦到的。
總結一下，也就是說Lock提供了比synchronized更多的功能。但是要注意以下幾點：
1）Lock不是Java語言內建的，synchronized是Java語言的關鍵字，因此是內建特性。Lock是一個類，通過這個類可以實現同步訪問；
2）Lock和synchronized有一點非常大的不同，採用synchronized不需要使用者去手動釋放鎖，當synchronized方法或者synchronized程式碼塊執行完之後，系統會自動讓執行緒釋放對鎖的佔用；而Lock則必須要使用者去手動釋放鎖，如果沒有主動釋放鎖，就有可能導致出現死鎖現象。
2 Lock
2.1 ReentrantLock
public class LockTest {
public static void main(String[] args) {
new LockTest().init();
}
private void init() {
final Outputer outputer = new Outputer();
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
outputer.output("kpioneer");
}
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
outputer.output("Jack");
}
}
}).start();
}
static class Outputer {
Lock lock = new ReentrantLock();
public void output(String name) {
int len = name.length();
lock.lock();
/**
*
*不管程式執行是否異常都要釋放鎖
* 否則再也進入不到改頁面
*/
try {
for (int i = 0; i < len; i++) {
System.out.print(name.charAt(i));
}
System.out.println();
} finally {
lock.unlock();
}
}
}
}
kpioneer Jack kpioneer Jack kpioneer Jack Jack kpioneer Jack kpioneer 省略...
2.2 ReentrantReadWriteLock
實中有這樣一種場景：對共享資源有讀和寫的操作，且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候，多個執行緒同時讀一個資源沒有任何問題，所以應該允許多個執行緒同時讀取共享資源；但是如果一個執行緒想去寫這些共享資源，就不應該允許其他執行緒對該資源進行讀和寫的操作了。
針對這種場景，JAVA的併發包提供了讀寫鎖ReentrantReadWriteLock，它表示兩個鎖，一個是讀操作相關的鎖，稱為共享鎖；一個是寫相關的鎖，稱為排他鎖，描述如下：
執行緒進入讀鎖的前提條件：
沒有其他執行緒的寫鎖，
沒有寫請求或者有寫請求，但呼叫執行緒和持有鎖的執行緒是同一個。
執行緒進入寫鎖的前提條件：
沒有其他執行緒的讀鎖
沒有其他執行緒的寫鎖
而讀寫鎖有以下三個重要的特性：
（1）公平選擇性：支援非公平（預設）和公平的鎖獲取方式，吞吐量還是非公平優於公平。
（2）重進入：讀鎖和寫鎖都支援執行緒重進入。
（3）鎖降級：遵循獲取寫鎖、獲取讀鎖再釋放寫鎖的次序，寫鎖能夠降級成為讀鎖。
public class ReadWriteLockTest {
public static void main(String[] args) {
final Queue q = new Queue();
for (int i = 0; i < 3; i++) {
new Thread() {
@Override
public void run() {
while (true) {
q.get();
}
}
}.start();
new Thread() {
@Override
public void run() {
while (true) {
q.put(new Random().nextInt(10000));
}
}
}.start();
}
}
}
class Queue {
//共享資料，只能有一個執行緒能寫該資料，但可以有多個執行緒同時讀該資料。
ReadWriteLock rwl = new ReentrantReadWriteLock();
private Object data = null;//共享資料，只能有一個執行緒能寫資料，但可以有多個執行緒讀該資料
public void get() {
//上讀鎖，其他執行緒只能讀不能寫
rwl.readLock().lock();
try {
System.out.println(Thread.currentThread().getName() + " be ready to read data!");
Thread.sleep((long) (Math.random() * 1000));
System.out.println(Thread.currentThread().getName() + " have read data :" + data);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
rwl.readLock().unlock();
}
}
public void put(Object data) {
//上寫鎖，不允許其他執行緒讀也不允許寫
rwl.writeLock().lock();
try {
System.out.println(Thread.currentThread().getName() + " be ready to write data!");
Thread.sleep((long) (Math.random() * 1000));
this.data = data;
System.out.println(Thread.currentThread().getName() + " have write data: " + data);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
rwl.writeLock().unlock();
}
}
}
Thread-0 be ready to read data! Thread-2 be ready to read data! Thread-2 have read data :null Thread-0 have read data :null Thread-1 be ready to write data! Thread-1 have write data: 4664 Thread-1 be ready to write data! Thread-1 have write data: 1849 Thread-3 be ready to write data! Thread-3 have write data: 75 Thread-3 be ready to write data! Thread-3 have write data: 8222 Thread-3 be ready to write data! Thread-3 have write data: 3056 Thread-3 be ready to write data! Thread-3 have write data: 6114 Thread-3 be ready to write data! Thread-3 have write data: 6376 省略...
3 鎖的相關概念介紹
在前面介紹了Lock的基本使用，這一節來介紹一下與鎖相關的幾個概念。
3.1 可重入鎖
如果鎖具備可重入性，則稱作為可重入鎖。像synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明瞭鎖的分配機制：基於執行緒的分配，而不是基於方法呼叫的分配。舉個簡單的例子，當一個執行緒執行到某個synchronized方法時，比如說method1，而在method1中會呼叫另外一個synchronized方法method2，此時執行緒不必重新去申請鎖，而是可以直接執行方法method2。
看下面這段程式碼就明白了：
class MyClass {
public synchronized void method1() {
method2();
}
public synchronized void method2() {
}
}
上述程式碼中的兩個方法method1和method2都用synchronized修飾了，假如某一時刻，執行緒A執行到了method1，此時執行緒A獲取了這個物件的鎖，而由於method2也是synchronized方法，假如synchronized不具備可重入性，此時執行緒A需要重新申請鎖。但是這就會造成一個問題，因為執行緒A已經持有了該物件的鎖，而又在申請獲取該物件的鎖，這樣就會執行緒A一直等待永遠不會獲取到的鎖。
而由於synchronized和Lock都具備可重入性，所以不會發生上述現象。
3.2 可中斷鎖
可中斷鎖：顧名思義，就是可以相應中斷的鎖。
在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。
如果某一執行緒A正在執行鎖中的程式碼，另一執行緒B正在等待獲取該鎖，可能由於等待時間過長，執行緒B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的執行緒中中斷它，這種就是可中斷鎖。
在前面演示lockInterruptibly()的用法時已經體現了Lock的可中斷性。
3.3 公平鎖
公平鎖即儘量以請求鎖的順序來獲取鎖。比如同是有多個執行緒在等待一個鎖，當這個鎖被釋放時，等待時間最久的執行緒（最先請求的執行緒）會獲得該所，這種就是公平鎖。
非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些執行緒永遠獲取不到鎖。
在Java中，synchronized就是非公平鎖，它無法保證等待的執行緒獲取鎖的順序。
而對於ReentrantLock和ReentrantReadWriteLock，它預設情況下是非公平鎖，但是可以設定為公平鎖。
看一下這2個類的原始碼就清楚了：
/**
* Base of synchronization control for this lock. Subclassed
* into fair and nonfair versions below. Uses AQS state to
* represent the number of holds on the lock.
*/
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
/**
* Performs {@link Lock#lock}. The main reason for subclassing
* is to allow fast path for nonfair version.
*/
abstract void lock();
/**
* Performs non-fair tryLock.tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
protected final boolean isHeldExclusively() {
// While we must in general read state before owner,
// we don't need to do so to check if current thread is owner
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
// Methods relayed from outer class
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
return getState() != 0;
}
/**
* Reconstitutes the instance from a stream (that is, deserializes it).
*/
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // reset to unlocked state
}
}
/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock.Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire.Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
另外在ReentrantLock類中定義了很多方法，比如：
isFair()//判斷鎖是否是公平鎖
isLocked()//判斷鎖是否被任何執行緒獲取了
isHeldByCurrentThread()//判斷鎖是否被當前執行緒獲取了
hasQueuedThreads()//判斷是否有執行緒在等待該鎖
在ReentrantReadWriteLock中也有類似的方法，同樣也可以設定為公平鎖和非公平鎖。不過要記住，ReentrantReadWriteLock並未實現Lock介面，它實現的是ReadWriteLock介面。
3.4 讀寫鎖
讀寫鎖將對一個資源（比如檔案）的訪問分成了2個鎖，一個讀鎖和一個寫鎖。
正因為有了讀寫鎖，才使得多個執行緒之間的讀操作不會發生衝突。
ReadWriteLock就是讀寫鎖，它是一個介面，ReentrantReadWriteLock實現了這個介面。
可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。