作者：royer
email: royerwang@21cn.com
日期：8/14/2001 1:12:48 PM
其實(shí)所有的死鎖最深層的原因就是一個(gè):資源競(jìng)爭(zhēng)
表現(xiàn)一:
    一個(gè)用戶A 訪問表A(鎖住了表A),然后又訪問表B
    另一個(gè)用戶B 訪問表B(鎖住了表B),然后企圖訪問表A
    這時(shí)用戶A由于用戶B已經(jīng)鎖住表B，它必須等待用戶B釋放表B,才能繼續(xù)，好了他老人家就只好老老實(shí)實(shí)在這等了
    同樣用戶B要等用戶A釋放表A才能繼續(xù)這就死鎖了
解決方法：
    這種死鎖是由于你的程序的BUG產(chǎn)生的，除了調(diào)整你的程序的邏輯別無他法
    仔細(xì)分析你程序的邏輯，
    1：盡量避免同時(shí)鎖定兩個(gè)資源
    2: 必須同時(shí)鎖定兩個(gè)資源時(shí)，要保證在任何時(shí)刻都應(yīng)該按照相同的順序來鎖定資源.
    
表現(xiàn)二:
    用戶A讀一條紀(jì)錄，然后修改該條紀(jì)錄
    這是用戶B修改該條紀(jì)錄
    這里用戶A的事務(wù)里鎖的性質(zhì)由共享鎖企圖上升到獨(dú)占鎖(for update),而用戶B里的獨(dú)占鎖由于A有共享鎖存在所以必須等A釋放掉共享鎖，而A由于B的獨(dú)占鎖而無法上升的獨(dú)占鎖也就不可能釋放共享鎖，于是出現(xiàn)了死鎖。
    這種死鎖比較隱蔽，但其實(shí)在稍大點(diǎn)的項(xiàng)目中經(jīng)常發(fā)生。
解決方法:
    讓用戶A的事務(wù)（即先讀后寫類型的操作),在select 時(shí)就是用Update lock
    語法如下：
    select * from table1 with(updlock) where ....

好了，本人目前總結(jié)到以上兩條，歡迎補(bǔ)充