執行緒中資源（一）

對於單執行緒來說，因為只有乙個實體，所以永遠都不需要擔心「兩個實體同時使用同乙個資源會發生什麼」這樣的問題。

有了併發就可以同時做多件事情了，但是兩個或多個執行緒彼此互相干涉的問題也就出現了。這就是我們將要討論的事

１.不正確地訪問資源

如果幾個執行緒同時讀乙個資源，此時不會更改資源，這時也不會需要考慮這個資源競爭這個問題。但是一旦涉及到寫操作，這便會涉及到競爭資源這個問題，這時也會對讀造成影響

２.解決共享資源競爭

對於併發工作，你需要某種方式來防止兩個任務訪問相同的資源，至少在關鍵階段不能出現這種情況。

防止這種衝突的方法就是當資源被乙個任務使用時，在其加上鎖。第乙個訪問某項資源的任務必須鎖定這項資源，使其他任務在其被解鎖之前，就無法訪問它，而在其被解鎖之時，另乙個任務就可以鎖定並使用它了。

共享資源一般是以物件形式存在的記憶體片段，但也可以是檔案，輸入／輸出埠，或者是印表機。要控制對共享資源的訪問，必須把它包裝進乙個物件。而我們會把它打上標記synchronized，下面是synchronized 的宣告方式

synchronized
void f(){}

所有物件都自動含有單一的鎖。當在物件上呼叫其任意synchronized 方法的時候，此物件都被加鎖，這時該物件上的其他synchronized 方法只有等到前乙個方法呼叫完畢並釋放了鎖之後才能被呼叫。

注意，在使用併發時，將域要設定為private ，否則synchronized 關鍵字就不能防止其他任務直接訪問域。

乙個任務可以多次獲得物件鎖。如果乙個方法在同乙個物件上呼叫了第二個方法，後者又呼叫了同一物件上的另乙個方法，就會發生這種情況。jvm負責跟蹤物件被加鎖的次數。如果乙個物件被解鎖，其計數就變為０。在任務（注意這裡我們用任務不用執行緒）第一次給物件加鎖的時候，計數變為１。每當這個相同的任務在這個物件上獲得鎖時，計數都會遞增。顯然，只有首頁獲得了鎖的任務才能允許繼續獲取多個鎖。每當任務離開乙個synchronized 方法，計數遞減，當計數為０的時候鎖被完全釋放，此時別的任務就可以使用這個資源。

針對每個類，也有乙個鎖，synchronized static方法可以在類的範圍內防止對static資料的併發訪問。

這個時候就有問題了，你應該什麼時候同步呢？，這裡要說一下brain的同步規則：

如果你正在寫乙個變數，它可能接下來將被另乙個執行緒讀取，或者正在讀取乙個上一次已經被另乙個執行緒寫過的變數，那麼你必須使用同步，並且，讀寫程序都必須用相同的監視器同步。

如果在你的類中有超過乙個方法正在處理臨界資料，那麼你必須同步所有相關的方法。如果只同步乙個方法，那麼其他方法將會隨意地忽略這個物件鎖，並可以在無任何懲罰的情況下被呼叫。這是很重要的一點:每個訪問臨界共享資源的方法都必須被同步，否則它們就不會正確地工作。

使用顯示的lock物件

private lock lock=new reentrantlock();
@override
public
intnext() finally 
}

在這裡我們顯示的用lock()和unlock()方法，注意慣用順序：

開始對lock()的呼叫，然後在try裡面做自己的工作，return必須在try子句中出現，以確保unlock()不會過早發生，從而將資料暴露給了第二個任務。

雖然try-finally所需的**比synchronized關鍵字要多，但是這也代表了顯示的lock物件的優點之一。如果在使用synchronized關鍵字時，某些事物失敗了就會丟擲乙個異常。但是你沒有機會去做任何清理工作，以維護系統使其處於良好狀態。有了顯示的lock物件，你就可以使用finally子句將系統維護在正確地狀態了。

一般解決特殊問題時，才顯示的lock物件。

執行緒中資源（一）

dashboard中資源釋放

SWT中資源基類Resouce

MFC中資源性指標

執行緒中資源（一）

dashboard中資源釋放

SWT中資源基類Resouce

MFC中資源性指標

相關推薦