遺留的一個.net專案，偶爾會出現一些比較詭異的問題，最近騰出功夫經過排查發現是由死鎖引起，下面是一張利用SQL Server Profiler追蹤到的死鎖狀況圖：

看到這張圖，說實話真是醉了，一個業務上還不算複雜的系統出現這麼複雜的死鎖挺罕見的，引起此問題的原因很簡單，就是該系統將90%的業務寫在了儲存過程，幾乎每一步操作都需要反覆的操作表來完成，結果導致偌大的伺服器記憶體利用率永遠在20%以下，CPU瞬時壓力巨大，沒有日誌，查詢bug也變得異常艱難，由於這種架構設計問題，從業務角度來修改似乎是不可能了，只能找一些臨時湊合的解決方案，比如修改隔離級別，死鎖超時時間等，關於這種由儲存過程構成的架構方案不想多說，想必很多架構設計人員不會去這麼設計，藉此想寫點關於資料庫事務隔離級別、鎖的基礎內容，本文就以微軟的

造成死鎖的必要條件，是在併發環境下，兩個（或多個）程序對同一個資源競爭造成的，如上圖，橢圓表示程序，矩形表示資源，可以看出是多個程序均佔有Batch這張表造成了死鎖，解決此問題必須先要搞清楚為什麼會有鎖以及鎖的基本知識。

在實際業務處理中，需要很多步動作連貫完成，比如最經典的銀行轉賬，A給B轉100元，必須要保證先從A賬戶減去100，然後在B賬戶加100，這個動作是不能間斷的，從程式角度看，為了保證這個動作完成，誕生了事務，事務有四個特性ACID，但事務僅僅只是一個概念，他不是具體的技術手段，那需要具體怎麼做才能保證事務ACID四個特性呢？關係型資料庫一般通過事務日誌和鎖的手段實現，事務日誌保證了原子性、一致性，事務日誌是由資料庫自行完成，因此一般開發人員接觸不到事務日誌，大概原理，就是在進行一切實際資料操作之前，都先寫好日誌，如果資料庫發生意外（比如斷電）後，及時可以通過日誌來自行恢復。鎖則保證了隔離性，保證多個事務能夠按照序列化的方式請求同一資料。

但現實世界是，很多操作需要並行，簡單粗暴的將所有操作（增刪改查）通過鎖來序列化執行必然行不通，因此需要更精細化來鎖定資源，從兩個方面入手，第一，針對鎖下手，增加鎖的型別：共享鎖（S）、獨佔鎖（X），還有一個特殊的更新鎖（U），還有幾乎不接觸的意向鎖、架構鎖等，針對每個鎖的解釋請參見《鎖模式》，他們之間是否相容的情況請看《鎖相容性》；第二，針對鎖資源範圍（鎖粒度），共有11個粒度，針對每個粒度的說明，MSDN有更詳盡的資料，這裡就不再貼上，附上鍊接：《鎖粒度和層次》。至於平時我們經常看到的樂觀鎖和悲觀鎖，可以參考Hibernate中的相關內容，文尾附了幾篇文章，可供參考。

一般來說，實際開發中，直接操作資料庫中各種鎖的機率相對比較少，更多的是利用資料庫提供的四個隔離級別，未提交讀、已提交讀、可重複讀、可序列化，還有一個特殊的基於行版本的已提交讀隔離級別，把它也可以歸到已提交讀內，基於行版本的隔離級別就是樂觀鎖的處理方式。那隔離級別和鎖是什麼關係？通俗來說，隔離級別是鎖的一個整體打包解決方案，我的理解是隔離封裝了鎖。針對這四種隔離，他們有各自的優點和缺點，如下表：

從表來看，隔離級別從上到下依次增加，級別越低，引起的問題也就比較多，比如髒讀、丟失更新等，但等級越高，也就意味著需要管理更多的鎖，無法並行處理，效能方面又受損，因此，我們在設計系統時，只需要根據業務需求選擇一種當下適合的隔離級別。一種隔離級別，就有一套利用鎖的方案，如此設計，目的就是為了平衡效能和功能。

如何選擇一種合適的隔離級別，首選需要了解髒讀、丟失更新、不可重複讀和幻讀的引發的問題，有篇文章舉得例子不錯，移步：《事務之間的相互影響》，看完這篇文章中的例子，大多數人基本就明白了，下面是用自己語言總結的：

髒讀：事務A讀到事務B尚未提交的修改（update，Insert，Delete）記錄後，事務B回滾了，事務A讀取到的就是不存在的資料；

不可重複讀：事務A第一次讀取後，事務B進行了修改（Delete、Update），再當事務A讀取時，發現數據在一個事務中前後不一；

幻讀：和不可重複讀類似，但幻讀針對Insert操作，當事務A第一讀取是表內有10行資料，此時事務B插入（Insert）了一條，當事務A再次讀取時發現變成了11行，造成幻覺；

丟失更新：事務A和事務B拿到同一份資料1，A在1的基礎上加1變成2後，此時B也在1的基礎上加2變成3，由於B提交晚，因此最終資料變成了3，覆蓋了事務A的操作，稱為丟失更新；

下面是從網路搜尋到到一張關於隔離級別和鎖關係的動態圖（上傳後居然不動了，對CSDN已經無力吐槽了-_-!）：

http://static.oschina.net/uploads/img/201207/09074335_5YM8.gif

最後附上一些寫的比較好的文章：