多線程開發(fā)藝術(shù)之死鎖的起因慌烧，預(yù)防和解決

產(chǎn)生死鎖的四個必要條件：

（1） 互斥條件：一個資源每次只能被一個進(jìn)程使用炫乓。

（2） 請求與保持條件：一個進(jìn)程因請求資源而阻塞時冀墨，對已獲得的資源保持不放闸衫。

（3） 不剝奪條件:進(jìn)程已獲得的資源，在末使用完之前诽嘉，不能強(qiáng)行剝奪蔚出。

（4） 循環(huán)等待條件:若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

二?鎖的分類??

鎖的類別有兩種分法：??

1.?從數(shù)據(jù)庫系統(tǒng)的角度來看：分為獨(dú)占鎖（即排它鎖）虫腋，共享鎖和更新鎖??

MS-SQL?Server?使用以下資源鎖模式骄酗。??

鎖模式?描述??

共享?(S) ：讀鎖，用于不更改或不更新數(shù)據(jù)的操作（只讀操作）岔乔，如?SELECT?語句酥筝。??

更新?(U) ：(介于共享和排它鎖之間），可以讓其他程序在不加鎖的條件下讀雏门，但本程序可以隨時更改嘿歌。

讀取表時使用更新鎖，而不使用共享鎖茁影，并將鎖一直保留到語句或事務(wù)的結(jié)束宙帝。UPDLOCK 的優(yōu)點(diǎn)是允許您讀取數(shù)據(jù)（不阻塞其它事務(wù)）并在以后更新數(shù)據(jù)，同時確保自從上次讀取數(shù)據(jù)后數(shù)據(jù)沒有被更改募闲。當(dāng)我們用UPDLOCK來讀取記錄時可以對取到的記錄加上更新鎖步脓，從而加上鎖的記錄在其它的線程中是不能更改的只能等本線程的事務(wù)結(jié)束后才能更改，我如下示例：

BEGIN TRANSACTION --開始一個事務(wù)

SELECT Qty

FROM myTable WITH (UPDLOCK)

WHERE Id in(1,2,3)

UPDATE myTable SET Qty = Qty - A.Qty

FROM myTable? AS A

INNER JOIN? @_Table AS B ON A.ID = B.ID

COMMIT TRANSACTION --提交事務(wù)

這樣在更新時其它的線程或事務(wù)在這些語句執(zhí)行完成前是不能更改ID是１浩螺，２靴患，３的記錄的．其它的都可以修改和讀，１要出，２鸳君，３的只能讀，要是修改的話只能等這些語句完成后才能操作.從而保證的數(shù)據(jù)的修改正確.

排它?(X)：寫鎖患蹂。 用于數(shù)據(jù)修改操作或颊，例如?INSERT、UPDATE?或?DELETE传于。確保不會同時同一資源進(jìn)行多重更新囱挑。??

意向鎖?用于建立鎖的層次結(jié)構(gòu)。意向鎖的類型為：意向共享?(IS)沼溜、意向排它?(IX)?以及與意向排它共享?(SIX)平挑。??

架構(gòu)鎖?在執(zhí)行依賴于表架構(gòu)的操作時使用。架構(gòu)鎖的類型為：架構(gòu)修改?(Sch-M)?和架構(gòu)穩(wěn)定性?(Sch-S)系草。??

大容量更新?(BU)?向表中大容量復(fù)制數(shù)據(jù)并指定了?TABLOCK?提示時使用通熄。??

共享鎖?

共享?(S)?鎖允許并發(fā)事務(wù)讀取?(SELECT)?一個資源否淤。資源上存在共享?(S)?鎖時，任何其它事務(wù)都不能修改數(shù)據(jù)棠隐。一旦已經(jīng)讀取數(shù)據(jù)石抡，便立即釋放資源上的共享?(S)?鎖，除非將事務(wù)隔離級別設(shè)置為可重復(fù)讀或更高級別助泽，或者在事務(wù)生存周期內(nèi)用鎖定提示保留共享?(S)?鎖啰扛。??

更新鎖?

更新?(U)?鎖可以防止通常形式的死鎖。一般更新模式由一個事務(wù)組成嗡贺，此事務(wù)讀取記錄隐解，獲取資源（頁或行）的共享?(S)?鎖，然后修改行诫睬，此操作要求鎖轉(zhuǎn)換為排它?(X)?鎖煞茫。如果兩個事務(wù)獲得了資源上的共享模式鎖，然后試圖同時更新數(shù)據(jù)摄凡，則一個事務(wù)嘗試將鎖轉(zhuǎn)換為排它?(X)?鎖续徽。共享模式到排它鎖的轉(zhuǎn)換必須等待一段時間，因?yàn)橐粋€事務(wù)的排它鎖與其它事務(wù)的共享模式鎖不兼容亲澡；發(fā)生鎖等待钦扭。第二個事務(wù)試圖獲取排它?(X)?鎖以進(jìn)行更新。由于兩個事務(wù)都要轉(zhuǎn)換為排它?(X)?鎖床绪，并且每個事務(wù)都等待另一個事務(wù)釋放共享模式鎖客情，因此發(fā)生死鎖。??

若要避免這種潛在的死鎖問題癞己，請使用更新?(U)?鎖膀斋。一次只有一個事務(wù)可以獲得資源的更新?(U)?鎖。如果事務(wù)修改資源痹雅，則更新?(U)?鎖轉(zhuǎn)換為排它?(X)?鎖仰担。否則，鎖轉(zhuǎn)換為共享鎖练慕。??

排它鎖?

排它?(X)?鎖可以防止并發(fā)事務(wù)對資源進(jìn)行訪問惰匙。其它事務(wù)不能讀取或修改排它?(X)?鎖鎖定的數(shù)據(jù)技掏。??

意向鎖?

意向鎖表示?SQL?Server?需要在層次結(jié)構(gòu)中的某些底層資源上獲取共享?(S)?鎖或排它?(X)?鎖铃将。例如，放置在表級的共享意向鎖表示事務(wù)打算在表中的頁或行上放置共享?(S)?鎖哑梳。在表級設(shè)置意向鎖可防止另一個事務(wù)隨后在包含那一頁的表上獲取排它?(X)?鎖劲阎。意向鎖可以提高性能，因?yàn)?SQL?Server?僅在表級檢查意向鎖來確定事務(wù)是否可以安全地獲取該表上的鎖鸠真。而無須檢查表中的每行或每頁上的鎖以確定事務(wù)是否可以鎖定整個表悯仙。?

意向鎖包括意向共享?(IS)龄毡、意向排它?(IX)?以及與意向排它共享?(SIX)。??

死鎖原理

??? 根據(jù)操作系統(tǒng)中的定義：死鎖是指在一組進(jìn)程中的各個進(jìn)程均占有不會釋放的資源锡垄，但因互相申請被其他進(jìn)程所站用不會釋放的資源而處于的一種永久等待狀態(tài)沦零。

死鎖的四個必要條件：

互斥條件(Mutual exclusion)：資源不能被共享，只能由一個進(jìn)程使用货岭。

請求與保持條件(Hold and wait)：已經(jīng)得到資源的進(jìn)程可以再次申請新的資源路操。

非剝奪條件(No pre-emption)：已經(jīng)分配的資源不能從相應(yīng)的進(jìn)程中被強(qiáng)制地剝奪。

循環(huán)等待條件(Circular wait)：系統(tǒng)中若干進(jìn)程組成環(huán)路千贯，該環(huán)路中每個進(jìn)程都在等待相鄰進(jìn)程正占用的資源屯仗。

對應(yīng)到SQL Server中，當(dāng)在兩個或多個任務(wù)中搔谴，如果每個任務(wù)鎖定了其他任務(wù)試圖鎖定的資源魁袜，此時會造成這些任務(wù)永久阻塞，從而出現(xiàn)死鎖敦第；這些資源可能是：單行(RID峰弹，堆中的單行)、索引中的鍵(KEY芜果，行鎖)垮卓、頁(PAG，8KB)师幕、區(qū)結(jié)構(gòu)(EXT粟按，連續(xù)的8頁)、堆或B樹(HOBT) 霹粥、表(TAB灭将，包括數(shù)據(jù)和索引)、文件(File后控，數(shù)據(jù)庫文件)庙曙、應(yīng)用程序?qū)Ｓ觅Y源(APP)、元數(shù)據(jù)(METADATA)浩淘、分配單元(Allocation_Unit)捌朴、整個數(shù)據(jù)庫(DB)。一個死鎖示例如下圖所示：

說明：T1张抄、T2表示兩個任務(wù)砂蔽；R1和R2表示兩個資源；由資源指向任務(wù)的箭頭(如R1->T1署惯，R2->T2)表示該資源被改任務(wù)所持有左驾；由任務(wù)指向資源的箭頭(如T1->S2，T2->S1)表示該任務(wù)正在請求對應(yīng)目標(biāo)資源；

其滿足上面死鎖的四個必要條件：

(1).互斥：資源S1和S2不能被共享诡右，同一時間只能由一個任務(wù)使用安岂；

(2).請求與保持條件：T1持有S1的同時，請求S2帆吻；T2持有S2的同時請求S1域那；

(3).非剝奪條件：T1無法從T2上剝奪S2，T2也無法從T1上剝奪S1猜煮；

(4).循環(huán)等待條件：上圖中的箭頭構(gòu)成環(huán)路琉雳，存在循環(huán)等待。

2.?死鎖排查

(1). 使用SQL Server的系統(tǒng)存儲過程sp_who和sp_lock友瘤，可以查看當(dāng)前數(shù)據(jù)庫中的鎖情況翠肘；進(jìn)而根據(jù)objectID(@objID)(SQL Server 2005)/ object_name(@objID)(Sql Server 2000)可以查看哪個資源被鎖，用dbcc ld(@blk)辫秧，可以查看最后一條發(fā)生給SQL Server的Sql語句束倍；

CREATE?Table?#Who(spid?int,

ecid?int,

status?nvarchar(50),

loginname?nvarchar(50),

hostname?nvarchar(50),

blk?int,

dbname?nvarchar(50),

cmd?nvarchar(50),

request_ID?int);

CREATE?Table?#Lock(spid?int,

dpid?int,

objid?int,

indld?int,

[Type]?nvarchar(20),

Resource?nvarchar(50),

Mode?nvarchar(10),

Status?nvarchar(10)

);

INSERT?INTO?#Who

EXEC?sp_who?active??--看哪個引起的阻塞，blk

INSERT?INTO?#Lock

EXEC?sp_lock??--看鎖住了那個資源id盟戏，objid

DECLARE?@DBName?nvarchar(20);

SET?@DBName='NameOfDataBase'

SELECT?#Who.*?FROM?#Who?WHERE?dbname=@DBName

SELECT?#Lock.*?FROM?#Lock

JOIN?#Who

ON?#Who.spid=#Lock.spid

AND?dbname=@DBName;

--最后發(fā)送到SQL?Server的語句

DECLARE?crsr?Cursor?FOR

SELECT?blk?FROM?#Who?WHERE?dbname=@DBName?AND?blk<>0;

DECLARE?@blk?int;

open?crsr;

FETCH?NEXT?FROM?crsr?INTO?@blk;

WHILE?(@@FETCH_STATUS=0)

BEGIN;

dbcc?inputbuffer(@blk);

FETCH?NEXT?FROM?crsr?INTO?@blk;

END;

close?crsr;

DEALLOCATE?crsr;

--鎖定的資源

SELECT?#Who.spid,hostname,objid,[type],mode,object_name(objid)?as?objName?FROM?#Lock

JOIN?#Who

ON?#Who.spid=#Lock.spid

AND?dbname=@DBName

WHERE?objid<>0;

DROP?Table?#Who;

DROP?Table?#Lock;

(2). 使用 SQL Server Profiler 分析死鎖: 將 Deadlock graph 事件類添加到跟蹤绪妹。此事件類使用死鎖涉及到的進(jìn)程和對象的 XML 數(shù)據(jù)填充跟蹤中的 TextData 數(shù)據(jù)列。SQL Server 事件探查器?可以將 XML 文檔提取到死鎖 XML (.xdl) 文件中柿究，以后可在 SQL Server Management Studio 中查看該文件邮旷。

3.?避免死鎖

上面1中列出了死鎖的四個必要條件，我們只要想辦法破其中的任意一個或多個條件蝇摸，就可以避免死鎖發(fā)生婶肩，一般有以下幾種方法(FROM Sql Server 2005聯(lián)機(jī)叢書)：

(1).按同一順序訪問對象。(注：避免出現(xiàn)循環(huán))

(2).避免事務(wù)中的用戶交互貌夕。(注：減少持有資源的時間律歼，較少鎖競爭)

(3).保持事務(wù)簡短并處于一個批處理中。(注：同(2)啡专，減少持有資源的時間)

(4).使用較低的隔離級別险毁。(注：使用較低的隔離級別（例如已提交讀）比使用較高的隔離級別（例如可序列化）持有共享鎖的時間更短，減少鎖競爭)

(5).使用基于行版本控制的隔離級別：2005中支持快照事務(wù)隔離和指定READ_COMMITTED隔離級別的事務(wù)使用行版本控制们童，可以將讀與寫操作之間發(fā)生的死鎖幾率降至最低：

SET ALLOW_SNAPSHOT_ISOLATION ON --事務(wù)可以指定 SNAPSHOT 事務(wù)隔離級別;

SET READ_COMMITTED_SNAPSHOT ON? --指定 READ_COMMITTED 隔離級別的事務(wù)將使用行版本控制而不是鎖定畔况。默認(rèn)情況下(沒有開啟此選項(xiàng)，沒有加with nolock提示)慧库，SELECT語句會對請求的資源加S鎖(共享鎖)跷跪；而開啟了此選項(xiàng)后，SELECT不會對請求的資源加S鎖完沪。

注意：設(shè)置 READ_COMMITTED_SNAPSHOT 選項(xiàng)時域庇，數(shù)據(jù)庫中只允許存在執(zhí)行 ALTER DATABASE 命令的連接。在 ALTER DATABASE 完成之前覆积，數(shù)據(jù)庫中決不能有其他打開的連接听皿。數(shù)據(jù)庫不必一定要處于單用戶模式中。

(6).使用綁定連接宽档。(注：綁定會話有利于在同一臺服務(wù)器上的多個會話之間協(xié)調(diào)操作尉姨。綁定會話允許一個或多個會話共享相同的事務(wù)和鎖(但每個回話保留其自己的事務(wù)隔離級別)，并可以使用同一數(shù)據(jù)吗冤，而不會有鎖沖突又厉。可以從同一個應(yīng)用程序內(nèi)的多個會話中創(chuàng)建綁定會話椎瘟，也可以從包含不同會話的多個應(yīng)用程序中創(chuàng)建綁定會話覆致。在一個會話中開啟事務(wù)(begin tran)后，調(diào)用exec sp_getbindtoken @Token out;來取得Token肺蔚，然后傳入另一個會話并執(zhí)行EXEC sp_bindsession @Token來進(jìn)行綁定(最后的示例中演示了綁定連接)煌妈。

4.?死鎖處理方法：

(1). 根據(jù)2中提供的sql，查看那個spid處于wait狀態(tài)宣羊，然后用kill spid來干掉(即破壞死鎖的第四個必要條件:循環(huán)等待)璧诵；當(dāng)然這只是一種臨時解決方案，我們總不能在遇到死鎖就在用戶的生產(chǎn)環(huán)境上排查死鎖仇冯、Kill sp之宿，我們應(yīng)該考慮如何去避免死鎖。

(2). 使用SET LOCK_TIMEOUT timeout_period(單位為毫秒)來設(shè)定鎖請求超時苛坚。默認(rèn)情況下比被，數(shù)據(jù)庫沒有超時期限(timeout_period值為-1，可以用SELECT @@LOCK_TIMEOUT來查看該值泼舱，即無限期等待)姐赡。當(dāng)請求鎖超過timeout_period時，將返回錯誤柠掂。timeout_period值為0時表示根本不等待项滑，一遇到鎖就返回消息。設(shè)置鎖請求超時涯贞，破環(huán)了死鎖的第二個必要條件(請求與保持條件)枪狂。

服務(wù)器:?消息?1222，級別?16宋渔，狀態(tài)?50州疾，行?1

已超過了鎖請求超時時段。

(3). SQL Server內(nèi)部有一個鎖監(jiān)視器線程執(zhí)行死鎖檢查皇拣，鎖監(jiān)視器對特定線程啟動死鎖搜索時严蓖，會標(biāo)識線程正在等待的資源薄嫡；然后查找特定資源的所有者，并遞歸地繼續(xù)執(zhí)行對那些線程的死鎖搜索颗胡，直到找到一個構(gòu)成死鎖條件的循環(huán)毫深。檢測到死鎖后，數(shù)據(jù)庫引擎?選擇運(yùn)行回滾開銷最小的事務(wù)的會話作為死鎖犧牲品毒姨，返回1205 錯誤哑蔫，回滾死鎖犧牲品的事務(wù)并釋放該事務(wù)持有的所有鎖，使其他線程的事務(wù)可以請求資源并繼續(xù)運(yùn)行弧呐。

5.?兩個死鎖示例及解決方法

5.1 SQL死鎖

(1).?測試用的基礎(chǔ)數(shù)據(jù)：

CREATE?TABLE?Lock1(C1?int?default(0));

CREATE?TABLE?Lock2(C1?int?default(0));

INSERT?INTO?Lock1?VALUES(1);

INSERT?INTO?Lock2?VALUES(1);

(2).?開兩個查詢窗口闸迷，分別執(zhí)行下面兩段sql

--Query?1

Begin?Tran

Update?Lock1?Set?C1=C1+1;

WaitFor?Delay?'00:01:00';

SELECT?*?FROM?Lock2

Rollback?Tran;

--Query?2

Begin?Tran

Update?Lock2?Set?C1=C1+1;

WaitFor?Delay?'00:01:00';

SELECT?*?FROM?Lock1

Rollback?Tran;

上面的SQL中有一句WaitFor Delay '00:01:00'，用于等待1分鐘俘枫，以方便查看鎖的情況腥沽。

(3).?查看鎖情況

在執(zhí)行上面的WaitFor語句期間，執(zhí)行第二節(jié)中提供的語句來查看鎖信息：

Query1中鸠蚪，持有Lock1中第一行(表中只有一行數(shù)據(jù))的行排他鎖(RID:X)巡球，并持有該行所在頁的意向更新鎖(PAG:IX)、該表的意向更新鎖(TAB:IX)邓嘹；Query2中酣栈，持有Lock2中第一行(表中只有一行數(shù)據(jù))的行排他鎖(RID:X)，并持有該行所在頁的意向更新鎖(PAG:IX)汹押、該表的意向更新鎖(TAB:IX)矿筝；

執(zhí)行完Waitfor，Query1查詢Lock2棚贾，請求在資源上加S鎖窖维，但該行已經(jīng)被Query2加上了X鎖；Query2查詢Lock1妙痹，請求在資源上加S鎖铸史，但該行已經(jīng)被Query1加上了X鎖；于是兩個查詢持有資源并互不相讓怯伊，構(gòu)成死鎖琳轿。

(4).?解決辦法

a).?SQL Server自動選擇一條SQL作死鎖犧牲品：運(yùn)行完上面的兩個查詢后，我們會發(fā)現(xiàn)有一條SQL能正常執(zhí)行完畢耿芹，而另一個SQL則報如下錯誤：

服務(wù)器:?消息?1205崭篡，級別?13，狀態(tài)?50吧秕，行?1

事務(wù)（進(jìn)程?ID??xx）與另一個進(jìn)程已被死鎖在??lock?資源上琉闪，且該事務(wù)已被選作死鎖犧牲品。請重新運(yùn)行該事務(wù)砸彬。

這就是上面第四節(jié)中介紹的鎖監(jiān)視器干活了颠毙。

b).?按同一順序訪問對象：顛倒任意一條SQL中的Update與SELECT語句的順序斯入。例如修改第二條SQL成如下：

--Query2

Begin?Tran

SELECT?*?FROM?Lock1--在Lock1上申請S鎖

WaitFor?Delay?'00:01:00';

Update?Lock2?Set?C1=C1+1;--Lock2:RID:X

Rollback?Tran;

當(dāng)然這樣修改也是有代價的，這會導(dǎo)致第一條SQL執(zhí)行完畢之前蛀蜜，第二條SQL一直處于阻塞狀態(tài)刻两。單獨(dú)執(zhí)行Query1或Query2需要約1分鐘，但如果開始執(zhí)行Query1時涵防，馬上同時執(zhí)行Query2闹伪，則Query2需要2分鐘才能執(zhí)行完沪铭；這種按順序請求資源從一定程度上降低了并發(fā)性壮池。

c).?SELECT語句加With(NoLock)提示：默認(rèn)情況下SELECT語句會對查詢到的資源加S鎖(共享鎖)，S鎖與X鎖(排他鎖)不兼容杀怠；但加上With(NoLock)后椰憋，SELECT不對查詢到的資源加鎖(或者加Sch-S鎖，Sch-S鎖可以與任何鎖兼容)赔退；從而可以是這兩條SQL可以并發(fā)地訪問同一資源橙依。當(dāng)然，此方法適合解決讀與寫并發(fā)死鎖的情況硕旗，但加With(NoLock)可能會導(dǎo)致臟讀窗骑。

SELECT?*?FROM?Lock2?WITH(NOLock)

SELECT?*?FROM?Lock1?WITH(NOLock)

d).?使用較低的隔離級別。SQL Server 2000支持四種事務(wù)處理隔離級別(TIL)漆枚，分別為：READ UNCOMMITTED创译、READ COMMITTED、REPEATABLE READ墙基、SERIALIZABLE软族；SQL Server 2005中增加了SNAPSHOT TIL。默認(rèn)情況下残制，SQL Server使用READ COMMITTED TIL立砸，我們可以在上面的兩條SQL前都加上一句SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，來降低TIL以避免死鎖初茶；事實(shí)上颗祝，運(yùn)行在READ UNCOMMITTED TIL的事務(wù)，其中的SELECT語句不對結(jié)果資源加鎖或加Sch-S鎖恼布，而不會加S鎖吐葵；但還有一點(diǎn)需要注意的是：READ UNCOMMITTED TIL允許臟讀，雖然加上了降低TIL的語句后桥氏，上面兩條SQL在執(zhí)行過程中不會報錯温峭，但執(zhí)行結(jié)果是一個返回1，一個返回2字支，即讀到了臟數(shù)據(jù)凤藏，也許這并不是我們所期望的奸忽。

e). 在SQL前加SET LOCK_TIMEOUT timeout_period，當(dāng)請求鎖超過設(shè)定的timeout_period時間后揖庄，就會終止當(dāng)前SQL的執(zhí)行栗菜，犧牲自己，成全別人蹄梢。

f).?使用基于行版本控制的隔離級別(SQL Server 2005支持)：開啟下面的選項(xiàng)后疙筹，SELECT不會對請求的資源加S鎖，不加鎖或者加Sch-S鎖禁炒，從而將讀與寫操作之間發(fā)生的死鎖幾率降至最低而咆；而且不會發(fā)生臟讀。啊

SET?ALLOW_SNAPSHOT_ISOLATION?ON

SET?READ_COMMITTED_SNAPSHOT?ON

??????????????? g). 使用綁定連接(使用方法見下一個示例幕袱。)

5.2?程序死鎖(SQL阻塞)

看一個例子：一個典型的數(shù)據(jù)庫操作事務(wù)死鎖分析暴备，按照我自己的理解，我覺得這應(yīng)該算是C#程序中出現(xiàn)死鎖们豌，而不是數(shù)據(jù)庫中的死鎖涯捻；下面的代碼模擬了該文中對數(shù)據(jù)庫的操作過程：

//略去的無關(guān)的code

SqlConnection?conn?=?new?SqlConnection(connectionString);

conn.Open();

SqlTransaction?tran?=?conn.BeginTransaction();

string?sql1?=?"Update?Lock1?SET?C1=C1+1";

string?sql2?=?"SELECT?*?FROM?Lock1";

ExecuteNonQuery(tran,?sql1);?//使用事務(wù):事務(wù)中Lock了Table

ExecuteNonQuery(null,?sql2);?//新開一個connection來讀取Table

public?static?void?ExecuteNonQuery(SqlTransaction?tran,?string?sql)

{

SqlCommand?cmd?=?new?SqlCommand(sql);

if?(tran?!=?null)

{

cmd.Connection?=?tran.Connection;

cmd.Transaction?=?tran;

cmd.ExecuteNonQuery();

}

else

{

using?(SqlConnection?conn?=?new?SqlConnection(connectionString))

{

conn.Open();

cmd.Connection?=?conn;

cmd.ExecuteNonQuery();

}

}

}

執(zhí)行到ExecuteNonQuery(null, sql2)時拋出SQL執(zhí)行超時的異常，下圖從數(shù)據(jù)庫的角度來看該問題：


?????代碼從上往下執(zhí)行望迎，會話1持有了表Lock1的X鎖障癌，且事務(wù)沒有結(jié)束，回話1就一直持有X鎖不釋放辩尊；而會話2執(zhí)行select操作涛浙，請求在表Lock1上加S鎖，但S鎖與X鎖是不兼容的对省，所以回話2的被阻塞等待蝗拿，不在等待中，就在等待中獲得資源蒿涎，就在等待中超時哀托。。劳秋。從中我們可以看到仓手，里面并沒有出現(xiàn)死鎖，而只是SELECT操作被阻塞了玻淑。也正因?yàn)椴皇菙?shù)據(jù)庫死鎖嗽冒，所以SQL Server的鎖監(jiān)視器無法檢測到死鎖。

?????? 我們再從C#程序的角度來看該問題：

?????? C#程序持有了表Lock1上的X鎖补履，同時開了另一個SqlConnection還想在該表上請求一把S鎖添坊，圖中已經(jīng)構(gòu)成了環(huán)路；太貪心了箫锤，結(jié)果自己把自己給鎖死了贬蛙。雨女。。

?????? 雖然這不是一個數(shù)據(jù)庫死鎖阳准，但卻是因?yàn)閿?shù)據(jù)庫資源而導(dǎo)致的死鎖氛堕，上例中提到的解決死鎖的方法在這里也基本適用，主要是避免讀操作被阻塞野蝇，解決方法如下：

a).?把SELECT放在Update語句前：SELECT不在事務(wù)中讼稚，且執(zhí)行完畢會釋放S鎖；

b).?把SELECT也放加入到事務(wù)中：ExecuteNonQuery(tran, sql2);

c).?SELECT加With(NOLock)提示：可能產(chǎn)生臟讀绕沈；

d).?降低事務(wù)隔離級別：SELECT語句前加SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED锐想；同上，可能產(chǎn)生臟讀七冲；

e).?使用基于行版本控制的隔離級別（同上例）痛倚。

g).?使用綁定連接：取得事務(wù)所在會話的token规婆，然后傳入新開的connection中澜躺；執(zhí)行EXEC sp_bindsession @Token后綁定了連接，最后執(zhí)行exec sp_bindsession null;來取消綁定抒蚜；最后需要注意的四點(diǎn)是：

(1). 使用了綁定連接的多個connection共享同一個事務(wù)和相同的鎖掘鄙，但各自保留自己的事務(wù)隔離級別；

(2). 如果在sql3字符串的“exec sp_bindsession null”換成“commit tran”或者“rollback tran”嗡髓，則會提交整個事務(wù)操漠，最后一行C#代碼tran.Commit()就可以不用執(zhí)行了(執(zhí)行會報錯，因?yàn)槭聞?wù)已經(jīng)結(jié)束了-,-)饿这。

(3). 開啟事務(wù)(begin tran)后浊伙，才可以調(diào)用exec sp_getbindtoken @Token out來取得Token；如果不想再新開的connection中結(jié)束掉原有的事務(wù)长捧，則在這個connection close之前嚣鄙，必須執(zhí)行“exec sp_bindsession null”來取消綁定連接，或者在新開的connectoin close之前先結(jié)束掉事務(wù)(commit/tran)串结。

(4). (Sql server 2005 聯(lián)機(jī)叢書)后續(xù)版本的 Microsoft SQL Server 將刪除該功能哑子。請避免在新的開發(fā)工作中使用該功能，并著手修改當(dāng)前還在使用該功能的應(yīng)用程序肌割。 請改用多個活動結(jié)果集 (MARS) 或分布式事務(wù)卧蜓。

tran?=?connection.BeginTransaction();

string?sql1?=?"Update?Lock1?SET?C1=C1+1";

ExecuteNonQuery(tran,?sql1);?//使用事務(wù):事務(wù)中Lock了測試表Lock1

string?sql2?=?@"DECLARE?@Token?varchar(255);

exec?sp_getbindtoken?@Token?out;

SELECT?@Token;";

string?token?=?ExecuteScalar(tran,?sql2).ToString();

string?sql3?=?"EXEC?sp_bindsession?@Token;Update?Lock1?SET?C1=C1+1;exec?sp_bindsession?null;";

SqlParameter?parameter?=?new?SqlParameter("@Token",?SqlDbType.VarChar);

parameter.Value?=?token;

ExecuteNonQuery(null,?sql3,?parameter);?//新開一個connection來操作測試表Lock1

tran.Commit();

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市把敞，隨后出現(xiàn)的幾起案子弥奸，更是在濱河造成了極大的恐慌，老刑警劉巖奋早，帶你破解...
    沈念sama閱讀 222,946評論 6贊 518
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件盛霎，死亡現(xiàn)場離奇詭異冒冬，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)摩渺，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評論 3贊 399
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門简烤，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人摇幻，你說我怎么就攤上這事横侦。” “怎么了绰姻？”我有些...
    開封第一講書人閱讀 169,716評論 0贊 364
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵枉侧，是天一觀的道長。 經(jīng)常有香客問我狂芋，道長榨馁，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 60,222評論 1贊 300
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任帜矾，我火速辦了婚禮翼虫，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘屡萤。我一直安慰自己珍剑，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 69,223評論 6贊 398
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布死陆。 她就那樣靜靜地躺著招拙，像睡著了一般。 火紅的嫁衣襯著肌膚如雪措译。 梳的紋絲不亂的頭發(fā)上别凤，一...
    開封第一講書人閱讀 52,807評論 1贊 314
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音领虹，去河邊找鬼规哪。 笑死，一個胖子當(dāng)著我的面吹牛掠械，可吹牛的內(nèi)容都是我干的由缆。 我是一名探鬼主播，決...
    沈念sama閱讀 41,235評論 3贊 424
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼猾蒂，長吁一口氣：“原來是場噩夢啊……” “哼均唉！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起肚菠，我...
    開封第一講書人閱讀 40,189評論 0贊 277
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤舔箭，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體层扶，經(jīng)...
    沈念sama閱讀 46,712評論 1贊 320
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡箫章，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,775評論 3贊 343
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了镜会。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片檬寂。...
    茶點(diǎn)故事閱讀 40,926評論 1贊 353
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖戳表，靈堂內(nèi)的尸體忽然破棺而出桶至，到底是詐尸還是另有隱情，我是刑警寧澤匾旭，帶...
    沈念sama閱讀 36,580評論 5贊 351
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布镣屹，位于F島的核電站，受9級特大地震影響价涝，放射性物質(zhì)發(fā)生泄漏女蜈。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,259評論 3贊 336
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一色瘩、第九天 我趴在偏房一處隱蔽的房頂上張望伪窖。 院中可真熱鬧，春花似錦泞遗、人聲如沸惰许。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0贊 25
  • 一樁弒父案史辙，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至佩伤，卻和暖如春聊倔，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背生巡。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1贊 274
  • 情欲美人皮
    我被黑心中介騙來泰國打工耙蔑， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人孤荣。 一個月前我還...
    沈念sama閱讀 49,368評論 3贊 379
  • 代替公主和親
    正文 我出身青樓甸陌，卻偏偏與公主長得像，于是被迫代替她去往敵國和親盐股。 傳聞我的和親對象是個殘疾皇子钱豁，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,930評論 2贊 361