public
inte***ce
ipoolable
}public
inte***ce
iobjectpool
<
t>
where
t : ipoolable
free方法要求池化物件的實現者將自身返回給物件池的空閒列表，這樣做的好處在於物件的使用者可以不用關注物件池的細節。
物件的管理這一問題，確實傷了不少腦筋。使用動態管理，我認為太過複雜，如果這麼做，至少要做到可銷毀物件的定義，怎麼樣才算可銷毀，是物件空閒了還是一定時間沒用了，還是當前數量超出了某個值等。上層應用使用不同物件的情況各有差異，如果簡單的用乙個標準定死，很難通用。
另一種比較常見的方式，我稱之為「樂觀獲取」，這種做法在無可用物件，並且物件總數達到數量上限時，會假定所有物件的使用者會及時的返回物件，此時請求者選擇sleep或者waitone等方式等待。我認為這是種雪上加霜的解決辦法，當所有可用物件已經被使用，並且達到了數量上限，這時候認為系達到物件使用的賣方市場，即供不應求。即使有限的物件被返回，也不能滿足更多的需求，最壞的情況是一些請求者一直等待。
基於此，我選擇了「悲觀獲取」的方式，這種做法在請求物件時，保證返回乙個正確物件，雖然這有可能造成系統中物件總數暫時超
出了數量限制，至少可以保證不會因為沒可用物件而使上層邏輯受阻。而當系統壓力減輕時，可通過控制返回物件的邏輯來銷毀多餘的物件。
物件池**如下：
//////
無需等待的物件池
///
class
unwaitobjectpool
<
t>
: iobjectpool
where
t : ipoolable,
new()
this
._minobjcount
=min;
this
._maxobjcount
=max;
this
._mutex
=new
object
();this
._freequeue
=new
queue
<
t>
();for
(inti =
0; i
<
min; i++)
}///
///有空閒物件則直接取出，如果沒有，直接建立，這裡無視數量上限
///
///
public
t getfreeobject()}}
return
newt();
}///
///返回物件，每次呼叫後如果空閒物件超出限制，則銷毀
///
///
public
void
releaseobject(t item)
this
.trytrimtomax();
}private
void
trytrimtomax()}}
樂觀鎖和悲觀鎖
1 悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...
樂觀鎖和悲觀鎖
併發衝突 在多使用者的環境下，如果使用者同時修改同乙個文件，就會造成衝突。典型的衝突有兩種 1 丟失更新 乙個使用者的更新記錄覆蓋了另乙個人的更新。如 使用者一 讀 寫 使用者二 讀 寫 那麼使用者一就把使用者二的更新覆蓋了。2 髒讀 乙個使用者更新資料未完成時，另乙個使用者就讀取資訊。使用者一 讀...
樂觀鎖和悲觀鎖
為什麼需要鎖 併發控制 在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 l 丟失更新 乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如 使用者a把值從6改為2，使用者b把值從2改為6，則使用者a丟失了他的更新。l 髒讀...