轉自：------------------------http://www.javaeye.com/topic/174591
生產者/消費者模型
有了信號量這個利器，我們就可以處理比較複雜的線程同步模型了。
首先，我們來看一個比較簡單的生產者/消費者模型。還是以Java代碼爲例。
public static final Object signal = new Object();
public static final char[] buf = new char[1024]; // 需要同步訪問的共享資源
// 生產者代碼
… produce() {
for(… ) { // 循環執行
synchronized(signal){
// 產生一些東西，放到 buf 共享資源中
signal.notify(); //然後通知消費者
signal.wait(); // 然後自己進入signal待召隊列
}
}
}
// 消費者代碼
… consume() {
for(… ) { // 循環執行
synchronized(signal){
signal.wait(); // 進入signal待召隊列，等待生產者的通知
// 讀取buf 共享資源裏面的東西
signal.notify(); // 然後通知生產者
}
}
}
上述的生產者/消費者模型的實現非常簡單，只用了一個信號量signal。這只是一段示意代碼。
實際上的生產者/消費者模型的實現可能非常複雜。可以引入buf已滿或者已空的判斷，可以引入更多的信號量，也可以引入一個環狀的buf鏈。但那些都是性能優化方面的工作，基本的信號量工作方式還是不變的。
生產者/消費者模型是典型的Coroutine。而且，當消費者或者生產者線程進入待召隊列的時候，當前的運行棧狀態就暫時保存在系統當中，這種狀況又是典型的Continuation。
因此，我們完全可以用信號量機制自己實現Coroutine和Continuation。其實，那些在語法層面上支持Coroutine和Continuation的語言，內部實現原理也是採用類似的信號量同步機制。
讀寫模型
讀寫模型是一個稍微複雜一些的模型。
一份共享資源允許多個讀者同時讀取。但是隻要有一個寫者在寫這份共享資源，任何其他的讀者和寫者都不能訪問這份共享資源。
讀寫模型實現起來，不僅需要信號量機制，還需要額外的讀者計數和寫者計數。
public static final Object signal = new Object();
public static int readers = 0;
public static int writers = 0;
// 讀者代碼
… read() {
for(… ) { // 循環執行
synchronized(signal){
while( writers > 0 )
signal.wait(); // 如果有人在寫，那麼就放棄執行，進入待召隊列
// 能夠到達這裏，說明沒有人在寫
readers ++ ; // 增加一個讀者計數，表示本線程在讀取
} // 這裏出了synchronized範圍,釋放同步鎖.以便其他線程讀取.
// 進行一些讀取操作
synchronized(signal){
readers --; // 讀取完成，減少一個讀者計數，表示本線程不在讀取
signal.notifyAll(); // 通知待召隊列裏面的所有其他線程
}
}
}
// 寫者代碼
… write() {
for(… ) { // 循環執行
synchronized(signal){
while( writers > 0 || readers > 0)
signal.wait();// 如果有人在寫或讀，那麼就放棄執行，進入待召隊列
// 能夠到達這裏，說明沒有人在寫，也沒有人在讀
writers ++ ; // 增加一個寫者計數，表示本線程在寫
// 進行一些寫操作
writers --; // 讀取完成，減少一個讀者計數，表示本線程不在寫
signal.notifyAll(); // 通知待召隊列裏面的所有其他線程
}
}
}
上述代碼只是一段示意代碼。實際應用中，人們通常抽取出來一個專門的讀寫同步鎖。
interface ReadWriteLock {
… getReadLock();
… releaseReadLock();
… getWriteLock();
… releaseWriteLock();
}
具體的實現原理也是類似的信號量同步機制。
class RWLock {
… readers, writers;
… synchronized … getReadLock() { // 相當於synchronized(this)
…
while( writers > 0 )
this.wait(); // 這裏我們把RWLock對象本身作爲信號量
readers++;
}
…synchronized … releaseReadLock(){ //相當於synchronized(this)
readers--;
this.notifyAll(); // // 這裏我們把RWLock對象本身作爲信號量
}
…synchronized … getWriteLock(){// 相當於synchronized(this)
while( writers > 0 || readers > 0 )
this.wait(); // 這裏我們把RWLock對象本身作爲信號量
writers++;
}
…synchronized … releaseWriteLock(){// 相當於synchronized(this)
writers--;
this.notifyAll(); // // 這裏我們把RWLock對象本身作爲信號量
}
}
具體用法是
public static final RWLock lock = new RWLock();
… read() {
lock.getReadLock();
// 讀取
lock.releaseReadLock();
}
… write() {
lock.getWriteLock();
// 讀取
lock.releaseWriteLock();
}
這種用法要求在執行一些處理之前，一定要執行某項特殊操作，處理之後一定也要執行某項特殊操作。這種人爲的順序性，無疑增加了代碼的耦合度，降低了代碼的獨立性。很有可能會成爲線程死鎖和資源操作衝突的根源。
這點一直讓我不安，可是沒有找到方法避免。畢竟，死鎖或者資源操作衝突，是線程的固有問題。
很巧的是，正在我惴惴不安的時候，我的一個朋友提供了一個信息。Sun公司根據JCR，決定在jdk1.5中引入關於concurrency（併發）的部分。
以下這個網址是concurrency部分的util.concurrent一個實現。非常好的信息。對於處理多線程併發問題，很有幫助。
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
裏面提供了一個ReadWriteLock類，標準用法如下。
Standard usage of ReadWriteLock:
class X {
ReadWriteLock rw;
// ...
public void read() throws InterruptedException {
rw.readLock().acquire();
try {
// ... do the read
}
finally {
rw.readlock().release()
}
}
public void write() throws InterruptedException {
rw.writeLock().acquire();
try {
// ... do the write
}
finally {
rw.writelock().release()
}
}
}
我們可以看到，ReadWriteLock同樣要求調用的順序——aquire()和release()。我對自己的例子增強了一點信心。
我又查看了WriterPreferenceReadWriteLock類，看到裏面成對的方法，startRead()，endRead()；startWrite()，endWrite()。我的心情完全放鬆了下來。我的思路雖然粗糙，但大體的方向是正確的。
線程池
線程是一種比較昂貴的資源。有些系統爲了重用線程，引入了線程池的機制。
線程池的工作原理如下：
首先，系統會啓動一定數量的線程。這些線程就構成了一個線程池。
當有任務要做的時候，系統就從線程池裏面選一個空閒的線程。然後把這個線程標記爲“正在運行”。然後把任務傳給這個線程執行。線程執行任務完成之後，就把自己標記爲“空閒”。
這個過程並不難以理解。難以理解的是，一般來說，線程執行完成之後，運行棧等系統資源就會釋放，線程對象就被回收了。一個已經完成的線程，又如何能回到線程池的空閒線程隊列中呢？
祕訣就在於，線程池裏面的線程永遠不會執行完成。線程池裏面的線程，都是一個無窮循環。具體代碼如下：
Thread pooledThread {
… theTask …. // theTask成員變量，表示要執行的任務
… run() {
while( true ) { // 永不停止的循環
signal.wait(); // 等待系統的通知
theTask.run(); // 執行任務
}
}
}
系統只需要調用 signal.notify() 就可以啓動一個空閒線程。