分析SIX鎖和鎖分區導致的死鎖

什么是SIX鎖？

官方文檔鎖模式中說到：

意向排他共享 (SIX)：保護針對層次結構中某些（而并非所有）低層資源請求或獲取的共享鎖以及針對某些（而并非所有）低層資源請求或獲取的意向排他鎖。 頂級資源允許使用并發 IS 鎖。 例如，獲取表上的 SIX 鎖也將獲取正在修改的頁上的意向排他鎖以及修改的行上的排他鎖。 雖然每個資源在一段時間內只能有一個 SIX 鎖，以防止其他事務對資源進行更新，但是其他事務可以通過獲取表級的 IS 鎖來讀取層次結構中的低層資源。

官方說明比較晦澀難懂，我嘗試用一種易懂的方式說明SIX是什么。

關于鎖有幾個概念：粒度、層次結構和鎖之間的兼容性。鎖是用來鎖定資源，而資源是包括很多種的，而這些不同的資源代表著不同的粒度。不同的資源間存在著層次結構，如表、分區、頁、行、鍵等。鎖的類型用很多種，粗略的分類包括共享鎖(S)、更新鎖(U)、排他鎖(X)和架構鎖(Sch)等，而不同類型的鎖，有些是互斥的，有些是兼容的。如共享鎖與其它類型的鎖相互兼容，排他鎖與其它的鎖類型互斥。

SQL Server分配鎖時，會沿著層次結構，從表級別開始分配鎖，然后到最下層的行和鍵。在分配鎖時，上級的資源會被分配意向鎖(I)，用來表示這個資源的下級某個資源已經被鎖定了。意向鎖也可以分為IS,IX,IU等類型。例如，更新表中某一行，需要在在行上分配X鎖，而在行所屬的數據頁中分配意向鎖IX，數據頁所屬的表上分配IX鎖。

如果一個會話的事務當前持有了某個表或者數據頁的S鎖，而它接下來又要去修改表中的某一個行。這種情況下，事務需要獲取行上的X鎖和表或數據頁上的IX鎖，但是SQL Server只允許一個會話在一個資源上獲取一個鎖。也就是說沒有辦法在已經獲得表或者頁級別的S鎖之后又分配IX給它。為了解決這個問題，于是就出現了兩者的結合體：S+IX=SIX。 同理，如果先持有IX，再去獲取S，也會得到SIX。

另外SQL Server中還有類似的鎖類型UIX(U+IX),SIU(S+IU),機理也是一樣的。這三種鎖被稱為轉換鎖。

什么是鎖分區？

首先不要把鎖分區(Lock Partitioning)和分區鎖(Partition Lock)搞混了。

官方文檔鎖分區：

對于大型計算機系統，在經常被引用的對象上放置的鎖可能會變成性能瓶頸，因為獲取和釋放鎖對內部鎖資源造成了爭用。鎖分區通過將單個鎖資源拆分為多個鎖資源而提高了鎖性能。此功能只適用于擁有 16 個或更多 CPU 的系統，它是自動啟用的，而且無法禁用。只有對象鎖可以分區。

鎖任務訪問幾個共享資源，其中兩個通過鎖分區進行優化：

• 調節鎖(Spinlock)。它控制對鎖資源（例如行或表）的訪問。

  不進行鎖分區，一個調節鎖就得管理單個鎖資源的所有鎖請求。在具有大量活動的系統上，在鎖請求等待釋放調節鎖時會出現資源爭用的現象。在這種情況下，獲取鎖可能變成了一個瓶頸，并且可能會對性能造成負面影響。

  為了減少對單個鎖資源的爭用，鎖分區將單個鎖資源拆分成多個鎖資源，以便將負荷分布到多個調節鎖上。

• 內存。它用于存儲鎖資源結構。

  獲取調節鎖后，鎖結構將存儲在內存中，然后即可對其進行訪問和可能的修改。將鎖訪問分布到多個資源中有助于消除在 CPU 之間傳輸內存塊的需要，這有助于提高性能。

獲取已分區資源的鎖時：

• 只能獲取單個分區的 NL、SCH-S、IS、IU 和 IX 鎖模式。

• 對于以分區 ID 0 開始并且按照分區 ID 順序排列的所有分區，必須獲取非 NL、SCH-S、IS、IU 和 IX 模式的共享鎖 (S)、排他鎖 (X) 和其他鎖。已分區資源的這些鎖將比相同模式中未分區資源的鎖占用更多的內存，因為每個分區都是一個有效的單獨鎖。內存的增加由分區數決定。Windows 性能監視器中 SQL Server 鎖計數器將顯示已分區和未分區鎖所使用內存信息。

啟動一個事務時，它將被分配給一個分區。對于此事務，可以分區的所有鎖請求都使用分配給該事務的分區。按照此方法，不同事務對相同對象的鎖資源的訪問被分布到不同的分區中。

通過一個示例觀察一下SIX和鎖分區：

create  table t2 (    id int identity(1,1) ,     col1 int,     col2 int     )     
go     
insert into t2     values (floor(rand()*100),floor(rand()*100))     
go 20
set transaction isolation level serializable    
begin tran     
insert into t2     values (floor(rand()*100),floor(rand()*100))     
select id from t2     where @@ROWCOUNT>0 and id=SCOPE_IDENTITY()     
SELECT resource_type, request_mode, resource_description,resource_lock_partition     
FROM   sys.dm_tran_locks     
WHERE  resource_type <> 'database' and request_session_id=@@SPID     
rollback

這個實例有24顆CPU，所以通過resource_lock_partition看到分區編號最到23了。因為SIX模式要獲取所有鎖分區，所以看到所有分區上都有SIX。

從圖中可以看出同一個事務中，不同的鎖資源可以使用不同的鎖分區。

實際案例分析

最近在做性能review時發現某些實例的Ring Buffer中記錄了一些死鎖，其中一個如下：

會話113持有了對象上的IX，需要再申請SIX。說明它修改數據后要去查詢數。

會話79持有了對象上的SIX，需要再申請SIX。這個就有點奇怪了，需要再仔細看看xml格式的死鎖信息。

<deadlock> 
    <victim-list> 
        <victimProcess 
id="process8809b88"/> 
    </victim-list> 
    <process-list> 
        <process id="process8809b88" 
taskpriority="0" logused="6844" waitresource="OBJECT: 6:1541580530:10 " 
waittime="967" ownerId="4638862771" transactionname="user_transaction" 
lasttranstarted="2016-06-06T16:45:14.617" XDES="0x8001d050" lockMode="SIX" 
schedulerid="1" kpid="41740" status="suspended" spid="113" sbid="2" ecid="0" 
priority="0" trancount="1" lastbatchstarted="2016-06-06T16:45:14.627" 
lastbatchcompleted="2016-06-06T16:45:14.627" clientapp=".Net SqlClient Data 
Provider" hostname="xxxx" hostpid="12552" loginname="xxx" 
isolationlevel="serializable (4)" xactid="4638862771" currentdb="6" 
lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> 
            <executionStack> 
                <frame procname="" 
line="3" stmtstart="220" 
sqlhandle="0x0200000072705a08155b23d8949f622375a2f263ba0d9099"></frame> 
            <frame procname="" line="1" 
sqlhandle="0x000000000000000000000000000000000000000000000000"></frame> 
    </executionStack> 
    <inputbuf> 
    (@0 bigint,@1 
varchar(20))insert [dbo].[CustomerVerify]([CustomerId], [VerifyRegisterCode]) 
values (@0, @1) select [VerifyID] from [dbo].[CustomerVerify] where @@ROWCOUNT 
&gt; 0 and [VerifyID] = scope_identity() 
</inputbuf> 
</process> 
<process id="process886c748" taskpriority="0" 
logused="7128" waitresource="OBJECT: 6:1541580530:0 " waittime="967" 
ownerId="4638862727" transactionname="user_transaction" 
lasttranstarted="2016-06-06T16:45:14.493" XDES="0xbe484e90" lockMode="SIX" 
schedulerid="11" kpid="35316" status="suspended" spid="79" sbid="2" ecid="0" 
priority="0" trancount="1" lastbatchstarted="2016-06-06T16:45:14.517" 
lastbatchcompleted="2016-06-06T16:45:14.517" clientapp=".Net SqlClient Data 
Provider" hostname="xxxxx" hostpid="29284" loginname="xxxxx" 
isolationlevel="serializable (4)" xactid="4638862727" currentdb="6" 
lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> 
<executionStack> 
    <frame procname="" line="3" 
stmtstart="220" 
sqlhandle="0x0200000072705a08155b23d8949f622375a2f263ba0d9099"></frame> 
<frame procname="" line="1" 
sqlhandle="0x000000000000000000000000000000000000000000000000"></frame> 
</executionStack> 
<inputbuf> 
(@0 bigint,@1 
varchar(20))insert [dbo].[CustomerVerify]([CustomerId], [VerifyRegisterCode]) 
values (@0, @1) select [VerifyID] from [dbo].[CustomerVerify] where @@ROWCOUNT 
&gt; 0 and [VerifyID] = scope_identity() 
</inputbuf> 
</process> 
</process-list> 
<resource-list> 
<objectlock lockPartition="10" objid="1541580530" 
subresource="FULL" dbid="6" objectname="" id="lock77e3c1b00" mode="IX" 
associatedObjectId="1541580530"> 
<owner-list> 
  <owner 
id="process886c748" mode="IX"/> 
</owner-list> 
<waiter-list> 
<waiter id="process8809b88" mode="SIX" 
requestType="wait"/> 
</waiter-list> 
</objectlock> 
<objectlock lockPartition="0" objid="1541580530" 
subresource="FULL" dbid="6" objectname="" id="lock628e080" mode="SIX" 
associatedObjectId="1541580530"> 
<owner-list> 
<owner 
id="process8809b88" mode="SIX"/> 
</owner-list> 
<waiter-list> 
<waiter id="process886c748" mode="SIX" 
requestType="wait"/> 
</waiter-list> 
</objectlock> 
</resource-list> 
</deadlock>

概括一下：

1.兩者執行同樣的語句。插入一條數據，然后把剛才插入的這條數據的自增ID取出來。堆表，無索引。

(@0 bigint,@1 varchar(20))insert [dbo].[CustomerVerify]([CustomerId], [VerifyRegisterCode]) values (@0, @1) select [VerifyID] from [dbo].[CustomerVerify] where @@ROWCOUNT > 0 and [VerifyID] = scope_identity()  
 

2. SPID 79持有鎖分區10上的IX，正在等待分配鎖分區0上的SIX.

    SPID 113持有鎖分區0上的SIX，正等待待分配鎖分區10上的SIX

3.會話的事務隔離級別都是可以序列化(isolationlevel="serializable (4)")。

基于以上，可以明白死鎖是怎么發生的:

113在插入數據時持有某個鎖分區的IX，假設這個鎖分區為N，然后它要查詢剛才插入的數據，所以轉換為SIX。SIX是需要分配所有鎖分區的，并且需要從第0鎖分區開始。分配到10分區時，發現10分區被與SIX不兼容的IX鎖給鎖定了，陷入等待。

79插入數據時被分配了IX鎖，這個鎖分區為第10分區，然后查詢數據時需要將IX轉換為SIX。于是從第0鎖分區開始分配SIX，但是第0分區已經被113的SIX鎖定，并且SIX與SIX是不兼容的，于是也陷入等待。

如何解決

總結前面的死鎖原因，問題就變成了：并發插入含有自增ID的堆表，并取出插入的自增ID，如何避免死鎖？

這種死鎖情況是非常非常罕見的。TF-1229可以禁用鎖分區的功能。個人覺得高并發的應用，與其禁用鎖分區來規避這種罕見情況，還不如設計好應用的重試機制。

有一點很奇怪，在上面的死鎖中，事務隔離級別是可序列化，而數據庫端是默認的已提交隔離級別。開發人員并沒設置連接會話的事務隔離級別，而這個會話的隔離級別卻改變了，這是什么原因呢？

我的分析是，程序中使用了Entity Framework，而EF在6.0之前的默認連接隔離級別是可序列化。開發人員直接拿來用，也沒有注意到這種問題。

參考：

What is the default transaction isolation level in Entity Framework when I issue “SaveChanges()”?

Tips to avoid deadlocks in Entity Framework applications