在今天的文章裡我想談下SQL Server使用的更高級的，輕量級的同步對象：闩鎖（Latch）。闩鎖是SQL Server存儲引擎使用輕量級同步對象，用來保護多線程訪問內存內結構。文章的第1部分我會介紹SQL Server裡為什麼需要闩鎖，在第2部分我會給你介紹各個闩鎖類型，還有你如何能對它們進行故障排除。
為什麼我們需要闩鎖？
闩鎖首次在SQL Server 7.0裡引入，同時微軟首次引入了行級別鎖（row-level locking）。對於行級別鎖引入闩鎖的概念是非常重要的，不然的話在內存中會出現丟失更新（Lost Updates）的現象。如我所說的，闩鎖是存儲引擎使用的輕量級同步對象，是SQL Server用來保護內存結構的。闩鎖只不過是類似於多線程編程裡的所謂的臨界區（Critcal Section）概念。
在傳統並發編程裡，臨界區是同時只能一個線程運行的代碼。闩鎖本身是個臨界區的特殊版本，因為它允許多個並發讀操作。在SQL Server的上下文裡這意味著多個線程可以並發讀取一個共享數據結構，例如內存中的頁，但是寫入共享數據結構必須是單個線程進行。
闩鎖是用來協調數據庫裡多個線程物理執行，然而鎖是基於選擇的事務隔離級別，用來邏輯獲得需要的隔離級別。作為開發者或DBA的你，你可以用不同方式影響鎖——例如通過SQL Server裡的隔離級別，或者通過各種可用鎖提示。另一方面闩鎖是不能以直接方式控制的。在SQL Server裡沒有闩鎖提示，也沒有可用闩鎖隔離級別。下表是鎖和闩鎖之間的比較：
鎖（Locks） 闩鎖（Latches）
控制…… 事務 線程
保護…… 數據庫內容 內存中數據結構
模式…… 共享的（Shared）， 保持（Keep），
更新（Update）， 共享的（Shared），
排它的（Exclusive）， 更新（Update），排它的（Exclusive），
意向的（Intension） 銷毀（Destroy）
死鎖…… 檢測並解決（detection&resolution） 通過嚴謹代碼來避免
保持在…… 鎖管理器的哈希表（Hashtable） 保護的數據結構（Protected Data Structure）
從表裡可以看到，闩鎖支持更細粒度保持（Keep）和銷毀（Destroy）模式。保持闩鎖主要用來引用計數，例如當你想知道在指定闩鎖上有多少其它闩鎖在等待。銷毀闩鎖是最有限制的一個（它甚至會阻塞保持闩鎖），當闩鎖被銷毀時會用到，例如當惰性寫入器（Lazy Writer）想要釋放內存中的頁時。我們先介紹下各種闩鎖模式，然後說下各個闩鎖模式的兼容性。
NL（空闩鎖）：
內部
未使用
KP（保持闩鎖）：
可以由多個任務同時持有
只被一個DT模式的闩鎖阻塞
SH（共享闩鎖）：
讀取數據頁的時候使用
可以由多個任務同事持有
阻塞EX模式和DT模式的闩鎖
UP（更新闩鎖）：
寫入系統分配頁面和tempdb的行版本化頁面時使用
一個這種模式的闩鎖只能被一個單獨的任務持有
EX（排它闩鎖）：
寫入數據頁的時候使用
一個這種模式的闩鎖只能被一個單獨的任務持有
DT（銷毀闩鎖）：
很少使用
一個這種模式的闩鎖只能被一個單獨的任務持有
在SQL Server裡，一致性不能只用鎖來獲得。SQL Server還是可以訪問沒被鎖管理器保護的共享數據結構，例如頁頭。還有SQL Server基於闩鎖基礎的其他組件也是，有單線程代碼路徑。好了，我們繼續講解SQL Server裡的各種闩鎖類型，還有如何對它們進行故障排除。
闩鎖類型與故障排除
SQL Server區分3個不同闩鎖類別
IO闩鎖
緩沖區闩鎖（BUF）
非緩沖區闩鎖（Non-BUF）
我們來詳細看下這3個不同類別。當在緩沖池的頁讀寫操作未完成——即當你讀自/寫入你的存儲子系統時（2者未同步），SQL Server會使用IO闩鎖（I/O Latches）。對於這些I/O闩鎖，SQL Server在統計信息裡以PAGEIOLATCH_為前綴出現。你可以在DMV sys.dm_os_wait_stats 查看下這些闩鎖類型的等待。
復制代碼 代碼如下:SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'PAGEIOLATCH_%'
使用這些闩鎖，SQL Server保證那些頁不會並發多次讀入緩存池，那些頁也不會從緩存池忽略，在那些頁需要被查詢訪問的時候。
除這些I/O闩鎖外，SQL Server也支持所謂的緩存區闩鎖（Buffer Latches），它用來保護緩沖池裡頁不會被並發運行的線程影響。這些闩鎖，SQL Server使用它們來阻止內存中的丟失更新（Lost Updates）。沒有這類闩鎖，在緩存池裡會有並發的讀寫頁，它們會引發主內存裡頁的損壞。對於這些緩存闩鎖，SQL Server在統計信息裡以PAGELATCH_為前綴出現。你可以在DMV sys.dm_os_wait_stats 查看下這些闩鎖類型的等待。這裡最重要的是你涉及了主內存的競爭，因為他們的等待類型名稱裡不包含IO字樣。
復制代碼 代碼如下: SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'PAGELATCH_%'
最後SQL Server內部使用所謂的非緩存區闩鎖（Non-Buffer Latches）來保護除緩沖池外的共享數據結構。對於這些非緩存闩鎖，SQL Server在統計信息裡以LATCH_為前綴出現。你可以在DMV sys.dm_os_wait_stats 查看下這些闩鎖類型的等待。
復制代碼 代碼如下: SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'LATCH_%'
但在這個DMV裡這些對於非緩存區闩鎖的等待只是SQL Server內部使用的各個闩鎖的概況信息，你可以在單獨的DMV sys.dm_os_latch_stats找到更詳細的信息。
復制代碼 代碼如下: SELECT * FROM sys.dm_os_latch_stats
SQL Server 2014內部使用163個闩鎖來同步共享數據結構的訪問。其中一個著名的闩鎖是FGCB_ADD_REMOVE，它用來保護文件組的文件組控制阻塞（ File Group Control Block （FGCB）），在以下特定操作期間：
文件增長（手動或自動）
增加/刪除文件組文件
重新計算填充比重（Recalculating proportional fill weightings）
在循環分配期間，通過文件組的文件回收。
當你看到這個闩鎖排在前列是，你肯定有太多自動增長操作的問題，原因是你數據庫糟糕的默認配置。當查詢嘗試讀/寫保護的數據結構且需要等待一個闩鎖時，查詢就會進入掛起狀態，直到闩鎖可以成功獲取。因此查詢經過的整個查詢生命周期包括運行（RUNNING），掛起（SUSPENDED），可運行（RUNNABLE），最後再次運行（RUNNING）。因此，當查詢長時間把持闩鎖時，強制共享數據結構保護才有意義。那是因為改變查詢狀態也意味著進行Windows系統裡的上下文切換，依據引入的CPU周期是個很昂貴的操作。
因此對於讀寫頻繁或極短時間內的共享數據結構上放上闩鎖沒有意義。在這個情況下，需要的上下文切換會殺死SQL Server的整體性能，它需要花費太多的時間來完成整個查詢生命周期（運行（RUNNING），掛起（SUSPENDED），可運行（RUNNABLE））。那就是是SQL Server引入的所謂自旋鎖(Spinlocks)。鎖管理器就是這樣數據結構的好例子：當鎖定或解鎖數據對象（例如記錄，頁等）時只需要單個線程訪問。但當你查看sys.dm_os_latch_stats時，你會發現沒有闩鎖保護鎖管理器本身。鎖管理器使用的哈希表裡對應的哈希桶使用自旋鎖來保護——LOCK_HASH自旋鎖。通過鎖管理器執行鎖定和解鎖操作前，必須獲得自旋鎖。
以上就是本文的全部內容，希望大家可以喜歡。
