問題，給人的印象是鎖會影響系統效能。這固然不然。但效能本身並不是鎖本身引起的，鎖也只是乙個系統呼叫，它本身的開銷是很小的，很多測試中，我們發現加鎖和去掉鎖後的效能幾乎沒有差別，為什麼了？
問題的關鍵在於，鎖帶來的效能下降，是因為鎖與鎖之間發生了碰撞，如果沒有鎖間的碰撞，則它所損害的效能是非常有限的。因此，要想減少因為使用鎖帶來的效能問題，就必須想辦法減少鎖之間的碰撞。
我常使用兩種方法來降低鎖之間的碰撞概率：
1.將需要鎖保證的資源分組，將乙個大鎖化為以組為單位的小鎖，如：建立多個佇列，每個佇列對應的一把鎖，這樣鎖佇列時，就不至於鎖住所有佇列（這裡有點類似於資料庫中的表鎖、行鎖等）；
2.獲取共享資源後即釋放鎖。這裡又有兩種場景：一是資源需要重複使用，二是資源取出後不重複使用。對於需要重複使用的應用考慮對該資源使用引用計數，對於不重複的則直接釋放鎖，如：
示例一：
char* msg = null;
if (!_queue.is_empty())
// 執行到這裡的時候，鎖已經解除掉
// 這裡使用從佇列裡取出的msg，如寫入檔案等
fputs(msg, fp);
示例二：
object* obj = null;
if (!_queue.is_empty())
// 執行到這裡的時候，鎖已經解除掉
// 這裡可以安全的使用obj了，而且已經不在鎖範圍之類
// 使用完全，需要放回到鎖：
sys::clockhelperlock(_lock);
if (obj->dec_refcount() > 0) // 如果已經沒人使用這個obj，則不用再放回佇列了，這裡也會刪除它以釋放資源
_queue.push_object(obj);
fputs(msg, fp);
鎖的認識lock
case 1 事務正在更新一張table，並且該事務並沒有處理結束。此時，使用select查詢出來的結果是？update之前的？之後的？始終沒有output，知道事務處理結束?1 始終處於被堵塞狀態 begin tran update student set name change where id...
必須走出小級別的技術認識誤區
就技術面而言,本人的體會是 一定要走出小級別的技術認識誤區.現在就拿周 圖來談談本人對 系統的拐頭和粘合 的認識 先看06年9月的中旬,粘合朝上走了,可以進場了.07年的2 3月,沒有拐頭向下,周 也僅僅是橫盤,因此可以繼續持有.07年6月下旬,開始拐頭向下了,那就需要退場了.07年8月初,又粘合了...
走出英語寫作的誤區
誤區 使用句型太複雜以致出錯 小作文的寫作強調的是內容連貫，句子通順，語言流暢，並且句子與句子之間能夠用恰當的關聯詞銜接起來，並不要求寫出多複雜的句子。但有些考生理解為只有句子長了，所用的從句多了才更純正，所以使用各種從句分詞等，致使文章言不達意，錯誤百出，效果適得其反。誤區 加入太多的想象成分，使...