1. 資料庫表中某行數據由於事務超時,連接斷開無法回滾被鎖,但在被鎖的表中查不到該行數據所在表，怎麼解鎖
鎖的概述
一. 為什麼要引入鎖
多個用戶同時對資料庫的並發操作時會帶來以下數據不一致的問題：
丟失更新
A，B兩個用戶讀同一數據並進行修改，其中一個用戶的修改結果破壞了另一個修改的結果，比如訂票系統
臟讀
A用戶修改了數據，隨後B用戶又讀出該數據，但A用戶因為某些原因取消了對數據的修改，數據恢復原值，此時B得到的數據就與資料庫內的數據產生了不一致
不可重復讀
A用戶讀取數據，隨後B用戶讀出該數據並修改，此時A用戶再讀取數據時發現前後兩次的值不一致
並發控制的主要方法是封鎖，鎖就是在一段時間內禁止用戶做某些操作以避免產生數據不一致
二 鎖的分類
鎖的類別有兩種分法：
1. 從資料庫系統的角度來看：分為獨占鎖（即排它鎖），共享鎖和更新鎖
MS sql Server 使用以下資源鎖模式。
鎖模式 描述
共享 (S) 用於不更改或不更新數據的操作（只讀操作），如 SELECT 語句。
更新 (U) 用於可更新的資源中。防止當多個會話在讀取、鎖定以及隨後可能進行的資源更新時發生常見形式的死鎖。
排它 (X) 用於數據修改操作，例如 INSERT、UPDATE 或 DELETE。確保不會同時同一資源進行多重更新。
意向鎖 用於建立鎖的層次結構。意向鎖的類型為：意向共享 (IS)、意向排它 (IX) 以及與意向排它共享 (SIX)。
架構鎖 在執行依賴於表架構的操作時使用。架構鎖的類型為：架構修改 (Sch-M) 和架構穩定性 (Sch-S)。
大容量更新 (BU) 向表中大容量復制數據並指定了 TABLOCK 提示時使用。
共享鎖
共享 (S) 鎖允許並發事務讀取 (SELECT) 一個資源。資源上存在共享 (S) 鎖時，任何其它事務都不能修改數據。一旦已經讀取數據，便立即釋放資源上的共享 (S) 鎖，除非將事務隔離級別設置為可重復讀或更高級別，或者在事務生存周期內用鎖定提示保留共享 (S) 鎖。
更新鎖
更新 (U) 鎖可以防止通常形式的死鎖。一般更新模式由一個事務組成，此事務讀取記錄，獲取資源（頁或行）的共享 (S) 鎖，然後修改行，此操作要求鎖轉換為排它 (X) 鎖。如果兩個事務獲得了資源上的共享模式鎖，然後試圖同時更新數據，則一個事務嘗試將鎖轉換為排它 (X) 鎖。共享模式到排它鎖的轉換必須等待一段時間，因為一個事務的排它鎖與其它事務的共享模式鎖不兼容；發生鎖等待。第二個事務試圖獲取排它 (X) 鎖以進行更新。由於兩個事務都要轉換為排它 (X) 鎖，並且每個事務都等待另一個事務釋放共享模式鎖，因此發生死鎖。
若要避免這種潛在的死鎖問題，請使用更新 (U) 鎖。一次只有一個事務可以獲得資源的更新 (U) 鎖。如果事務修改資源，則更新 (U) 鎖轉換為排它 (X) 鎖。否則，鎖轉換為共享鎖。
排它鎖
排它 (X) 鎖可以防止並發事務對資源進行訪問。其它事務不能讀取或修改排它 (X) 鎖鎖定的數據。
意向鎖
意向鎖表示 SQL Server 需要在層次結構中的某些底層資源上獲取共享 (S) 鎖或排它 (X) 鎖。例如，放置在表級的共享意向鎖表示事務打算在表中的頁或行上放置共享 (S) 鎖。在表級設置意向鎖可防止另一個事務隨後在包含那一頁的表上獲取排它 (X) 鎖。意向鎖可以提高性能，因為 SQL Server 僅在表級檢查意向鎖來確定事務是否可以安全地獲取該表上的鎖。而無須檢查表中的每行或每頁上的鎖以確定事務是否可以鎖定整個表。
意向鎖包括意向共享 (IS)、意向排它 (IX) 以及與意向排它共享 (SIX)。
鎖模式
描述
意向共享 (IS) 通過在各資源上放置 S 鎖，表明事務的意向是讀取層次結構中的部分（而不是全部）底層資源。
意向排它 (IX) 通過在各資源上放置 X 鎖，表明事務的意向是修改層次結構中的部分（而不是全部）底層資源。IX 是 IS 的超集。與意向排它共享 (SIX) 通過在各資源上放置 IX 鎖，表明事務的意向是讀取層次結構中的全部底層資源並修改部分（而不是全部）底層資源。允許頂層資源上的並發 IS 鎖。例如，表的 SIX 鎖在表上放置一個 SIX 鎖（允許並發 IS 鎖），在當前所修改頁上放置 IX 鎖（在已修改行上放置 X 鎖）。雖然每個資源在一段時間內只能有一個 SIX 鎖，以防止其它事務對資源進行更新，但是其它事務可以通過獲取表級的 IS 鎖來讀取層次結構中的底層資源。
獨占鎖：只允許進行鎖定操作的程序使用，其他任何對他的操作均不會被接受。執行數據更新命令時，SQL Server會自動使用獨占鎖。當對象上有其他鎖存在時，無法對其加獨占鎖。
共享鎖：共享鎖鎖定的資源可以被其他用戶讀取，但其他用戶無法修改它，在執行Select時，SQL Server會對對象加共享鎖。
更新鎖：當SQL Server准備更新數據時，它首先對數據對象作更新鎖鎖定，這樣數據將不能被修改，但可以讀取。等到SQL Server確定要進行更新數據操作時，他會自動將更新鎖換為獨占鎖，當對象上有其他鎖存在時，無法對其加更新鎖。
2. 從程序員的角度看：分為樂觀鎖和悲觀鎖。
樂觀鎖：完全依靠資料庫來管理鎖的工作。
悲觀鎖：程序員自己管理數據或對象上的鎖處理。
MS SQL Server 使用鎖在多個同時在資料庫內執行修改的用戶間實現悲觀並發控制
三 鎖的粒度
鎖粒度是被封鎖目標的大小，封鎖粒度小則並發性高，但開銷大，封鎖粒度大則並發性低但開銷小
SQL Server支持的鎖粒度可以分為為行、頁、鍵、鍵范圍、索引、表或資料庫獲取鎖
資源描述
RID 行標識符。用於單獨鎖定表中的一行。
鍵 索引中的行鎖。用於保護可串列事務中的鍵范圍。
頁 8 千位元組 (KB) 的數據頁或索引頁。
擴展盤區 相鄰的八個數據頁或索引頁構成的一組。
表 包括所有數據和索引在內的整個表。
DB 資料庫。
四 鎖定時間的長短
鎖保持的時間長度為保護所請求級別上的資源所需的時間長度。
用於保護讀取操作的共享鎖的保持時間取決於事務隔離級別。採用 READ COMMITTED 的默認事務隔離級別時，只在讀取頁的期間內控制共享鎖。在掃描中，直到在掃描內的下一頁上獲取鎖時才釋放鎖。如果指定 HOLDLOCK 提示或者將事務隔離級別設置為 REPEATABLE READ 或 SERIALIZABLE，則直到事務結束才釋放鎖。
根據為游標設置的並發選項，游標可以獲取共享模式的滾動鎖以保護提取。當需要滾動鎖時，直到下一次提取或關閉游標（以先發生者為准）時才釋放滾動鎖。但是，如果指定 HOLDLOCK，則直到事務結束才釋放滾動鎖。
用於保護更新的排它鎖將直到事務結束才釋放。
如果一個連接試圖獲取一個鎖，而該鎖與另一個連接所控制的鎖沖突，則試圖獲取鎖的連接將一直阻塞到：
將沖突鎖釋放而且連接獲取了所請求的鎖。
連接的超時間隔已到期。默認情況下沒有超時間隔，但是一些應用程序設置超時間隔以防止無限期等待
五 SQL Server 中鎖的自定義
1 處理死鎖和設置死鎖優先順序
死鎖就是多個用戶申請不同封鎖，由於申請者均擁有一部分封鎖權而又等待其他用戶擁有的部分封鎖而引起的無休止的等待可以使用SET DEADLOCK_PRIORITY控制在發生死鎖情況時會話的反應方式。如果兩個進程都鎖定數據，並且直到其它進程釋放自己的鎖時，每個進程才能釋放自己的鎖，即發生死鎖情況。
2 處理超時和設置鎖超時持續時間。
@@LOCK_TIMEOUT 返回當前會話的當前鎖超時設置，單位為毫秒
SET LOCK_TIMEOUT 設置允許應用程序設置語句等待阻塞資源的最長時間。當語句等待的時間大於 LOCK_TIMEOUT 設置時，系統將自動取消阻塞的語句，並給應用程序返回"已超過了鎖請求超時時段"的 1222 號錯誤信息
示例
下例將鎖超時期限設置為 1，800 毫秒。
SET LOCK_TIMEOUT 1800
3) 設置事務隔離級別。
4 ) 對 SELECT、INSERT、UPDATE 和 DELETE 語句使用表級鎖定提示。
5) 配置索引的鎖定粒度
可以使用 sp_indexoption 系統存儲過程來設置用於索引的鎖定粒度
六 查看鎖的信息 1 執行 EXEC SP_LOCK 報告有關鎖的信息
2 查詢分析器中按Ctrl+2可以看到鎖的信息
七 使用注意事項
如何避免死鎖
1 使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務；
2 設置死鎖超時參數為合理范圍，如：3分鍾-10分種；超過時間，自動放棄本次操作，避免進程懸掛；
3 優化程序，檢查並避免死鎖現象出現；
4 .對所有的腳本和SP都要仔細測試，在正是版本之前。
5 所有的SP都要有錯誤處理（通過@error）
6 一般不要修改SQL Server事務的默認級別。不推薦強行加鎖
八 幾個有關鎖的問題
1 如何鎖一個表的某一行
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDSELECT * FROM table ROWLOCK WHERE id =
1
2 鎖定資料庫的一個表
SELECT * FROM table WITH (HOLDLOCK)
加鎖語句：
sybase：update 表 set col1=col1 where 1=0 ;MS SQL：select col1 from 表 (tablockx) where 1=0 ;oracle：LOCK TABLE 表 IN EXCLUSIVE MODE ；
加鎖後其它人不可操作，直到加鎖用戶解鎖，用commit或rollback解鎖
幾個例子幫助大家加深印象，設table1(A，B，C)
A B C
a1 b1 c1
a2 b2 c2
a3 b3 c3
1）排它鎖
新建兩個連接，在第一個連接中執行以下語句
begin tranupdate table1set A='aa'where B='b2'waitfor delay '00：00：30'
--等待30秒commit tran
在第二個連接中執行以下語句
begin transelect * from table1where B='b2'commit tran
若同時執行上述兩個語句，則select查詢必須等待update執行完畢才能執行即要等待30秒
2）共享鎖
在第一個連接中執行以下語句
begin transelect * from table1 holdlock -holdlock人為加鎖where B='b2'waitfor delay '00：00：30'
--等待30秒commit tran
在第二個連接中執行以下語句
begin transelect A，C from table1where B='b2'update table1set A='aa'where B='b2'commit tran
若同時執行上述兩個語句，則第二個連接中的select查詢可以執行，而update必須等待第一個事務釋放共享鎖轉為排它鎖後才能執行 即要等待30秒
3）死鎖
增設table2(D，E)
D E
d1 e1
d2 e2
在第一個連接中執行以下語句
begin tranupdate table1set A='aa'where B='b2'waitfor delay '00：00：30'update table2set D='d5'where E='e1'commit tran
在第二個連接中執行以下語句
begin tranupdate table2set D='d5'where E='e1'waitfor delay '00：00：10'update table1set A='aa'where B='b2'commit tran
同時執行，系統會檢測出死鎖，並中止進程
補充一點：
SQL Server 2000支持的表級鎖定提示
HOLDLOCK 持有共享鎖，直到整個事務完成，應該在被鎖對象不需要時立即釋放，等於SERIALIZABLE事務隔離級別
NOLOCK 語句執行時不發出共享鎖，允許臟讀 ，等於 READ UNCOMMITTED事務隔離級別
PAGLOCK 在使用一個表鎖的地方用多個頁鎖
READPAST 讓SQL Server跳過任何鎖定行，執行事務，適用於READ UNCOMMITTED事務隔離級別只跳過RID鎖，不跳過頁，區域和表鎖
ROWLOCK 強制使用行鎖
TABLOCKX 強制使用獨占表級鎖，這個鎖在事務期間阻止任何其他事務使用這個表
UPLOCK 強制在讀表時使用更新而不用共享鎖
應用程序鎖：
應用程序鎖就是客戶端代碼生成的鎖，而不是SQL Server本身生成的鎖
處理應用程序鎖的兩個過程
sp_getapplock 鎖定應用程序資源
sp_releaseapplock 為應用程序資源解鎖
注意： 鎖定資料庫的一個表的區別
SELECT * FROM table WITH (HOLDLOCK) 其他事務可以讀取表，但不能更新刪除
SELECT * FROM table WITH (TABLOCKX) 其他事務不能讀取表，更新和刪除
2. MySQL資料庫表被鎖、解鎖，刪除事務
在程序員的職業生涯中，總會遇到資料庫表被鎖的情況，前些天就又撞見一次。由於業務突發需求，各個部門都在批量操作、導出數據，而資料庫又未做讀寫分離，結果就是：資料庫的某張表被鎖了！
用戶反饋系統部分功能無法使用，緊急排查，定位是資料庫表被鎖，然後進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點贊收藏，以備不時之需。
用戶反饋某功能頁面報502錯誤，於是第一時間看服務是否正常，資料庫是否正常。在控制台看到資料庫CPU飆升，堆積大量未提交事務，部分事務已經阻塞了很長時間，基本定位是資料庫層出現問題了。
查看阻塞事務列表，發現其中有鎖表現象，本想利用控制台直接結束掉阻塞的事務，但控制台賬號許可權有限，於是通過客戶端登錄對應賬號將鎖表事務kill掉，才避免了情況惡化。
下面就聊聊，如果當突然面對類似的情況，我們該如何緊急響應？
想像一個場景，當然也是軟體工程師職業生涯中會遇到的一種場景：原本運行正常的程序，某一天突然資料庫的表被鎖了，業務無法正常運轉，那麼我們該如何快速定位是哪個事務鎖了表，如何結束對應的事物？
首先最簡單粗暴的方式就是：重啟MySQL。對的，網管解決問題的神器——「重啟」。至於後果如何，你能不能跑了，要你自己三思而後行了！
重啟是可以解決表被鎖的問題的，但針對線上業務很顯然不太具有可行性。
下面來看看不用跑路的解決方案：
遇到資料庫阻塞問題，首先要查詢一下表是否在使用。
如果查詢結果為空，那麼說明表沒在使用，說明不是鎖表的問題。
如果查詢結果不為空，比如出現如下結果：
則說明表（test）正在被使用，此時需要進一步排查。
查看資料庫當前的進程，看看是否有慢SQL或被阻塞的線程。
執行命令：
該命令只顯示當前用戶正在運行的線程，當然，如果是root用戶是能看到所有的。
在上述實踐中，阿里雲控制台之所以能夠查看到所有的線程，猜測應該使用的就是root用戶，而筆者去kill的時候，無法kill掉，是因為登錄的用戶非root的資料庫賬號，無法操作另外一個用戶的線程。
如果情況緊急，此步驟可以跳過，主要用來查看核對：
如果情況緊急，此步驟可以跳過，主要用來查看核對：
看事務表INNODB_TRX中是否有正在鎖定的事務線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個sleep的線程事務一直沒有commit或者rollback，而是卡住了，需要手動kill掉。
搜索的結果中，如果在事務表發現了很多任務，最好都kill掉。
執行kill命令：
對應的線程都執行完kill命令之後，後續事務便可正常處理。
針對緊急情況，通常也會直接操作第一、第二、第六步。
這里再補充一些MySQL鎖相關的知識點：資料庫鎖設計的初衷是處理並發問題，作為多用戶共享的資源，當出現並發訪問的時候，資料庫需要合理地控制資源的訪問規則，而鎖就是用來實現這些訪問規則的重要數據結構。
根據加鎖的范圍，MySQL裡面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（metadata lock，MDL)。
表鎖是在Server層實現的，ALTER TABLE之類的語句會使用表鎖，忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現，而對於InnoDB來說，一般會採用行級鎖。畢竟鎖住整張表影響范圍太大了。
另外一個表級鎖是MDL（metadata lock），用於並發情況下維護數據的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時會被自動加上。
常見的一種鎖表場景就是有事務操作處於：Waiting for table metadata lock狀態。
MySQL在進行alter table等DDL操作時，有時會出現Waiting for table metadata lock的等待場景。
一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態，後續對該表的任何操作（包括讀）都無法進行，因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現了鎖等待隊列，就會造成災難性的後果。
通過show processlist可以看到表上有正在進行的操作（包括讀），此時alter table語句無法獲取到metadata 獨占鎖，會進行等待。
通過show processlist看不到表上有任何操作，但實際上存在有未提交的事務，可以在information_schema.innodb_trx中查看到。在事務沒有完成之前，表上的鎖不會釋放，alter table同樣獲取不到metadata的獨占鎖。
處理方法：通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然後kill掉，讓其回滾。
通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進行中的事務。很可能是因為在一個顯式的事務中，對表進行了一個失敗的操作（比如查詢了一個不存在的欄位），這時事務沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。
處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。
總之，alter table的語句是很危險的（核心是未提交事務或者長事務導致的），在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務、也沒有顯式事務中的報錯語句。
如果有alter table的維護任務，在無人監管的時候運行，最好通過lock_wait_timeout設置好超時時間，避免長時間的metedata鎖等待。
關於MySQL的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。
3. mysql事務與鎖的關系
事務
事務是恢復和並發控制的基本單位。
事務的ACID特性：
1）原子性
一個事務是一個不可分割的工作單位，事務中包含的所有操作，要麼都做，要麼都不做。支持回滾
2）一致性
事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的
3）隔離性
一個事務的執行不能被其它事務干擾。即一個事務內部的操作及使用的數據對並發的其它事務是隔離的，並發執行的各個事務之間不能互相干擾
4）持久性
一個事務一旦提交，對資料庫中數據的改變就應該是永久性的。接下來的操作或故障不應該對其有任何影響
4. 什麼是事務什麼是鎖
事務與鎖是不同的。事務具有ACID（原子性、一致性、隔離性和持久性），鎖是用於解決隔離性的一種機制。事務的隔離級別通過鎖的機制來實現。另外鎖有不同的粒度，同時事務也是有不同的隔離級別的（一般有四種：讀未提交Read uncommitted，
讀已提交Read committed，
可重復讀Repeatable read，
可串列化Serializable）。
在具體的程序設計中，開啟事務其實是要資料庫支持才行的，如果資料庫本身不支持事務，那麼仍然無法確保你在程序中使用的事務是有效的。
鎖可以分為樂觀鎖和悲觀鎖：
悲觀鎖：認為在修改資料庫數據的這段時間里存在著也想修改此數據的事務；
樂觀鎖：認為在短暫的時間里不會有事務來修改此資料庫的數據；
我們一般意義上講的鎖其實是指悲觀鎖，在數據處理過程中，將數據置於鎖定狀態（由資料庫實現）
如果開啟了事務，在事務沒提交之前，別人是無法修改該數據的；如果rollback，你在本次事務中的修改將撤消（不是別人修改的會沒有，因為別人此時無法修改）。當然，前提是你使用的資料庫支持事務。還有一個要注意的是，部分資料庫支持自定義SQL鎖覆蓋事務隔離級別默認的鎖機制，如果使用了自定義的鎖，那就另當別論。
重點：一般事務使用的是悲觀鎖（具有排他性）
5. mysql如何用事務和鎖 鎖住某一行數據，使得不允許兩個用戶同時讀取一行數據！！
1、在mysql資料庫中如何鎖定一行數據，保證不被其他的操作影響。
6. 事務鎖與並發問題是什麼關系
事務鎖是為了應對並發問題的一種解決機制，在事務獲取數據塊當前狀態的依賴關系（如通過讀取或修改數據）之前，它必須保護自己不受其他事務對同一數據進行修改的影響，事務通過請求鎖定數據塊來達到此目的。
1.鎖模式如果某個事務已獲得特定數據的鎖，則其他事務不能獲得與該鎖模式發生沖突的鎖。如果事務請求的鎖模式與已授予同一數據的鎖發生沖突，則資料庫引擎實例將暫停事務請求直到第一個鎖被釋放。鎖有多種模式，包括共享鎖、更新鎖、排他鎖等。
（1)共享鎖（S鎖）共享鎖允許並發事務在封閉式並發事務下讀取資源。有關詳細信息，請參閱「2.1.3並發事務」的類型。資源上存在共享鎖時，任何其他事務都不能修改數據。讀取操作一完成，就立即釋放資源上的共享鎖，除非將事務隔離級別設置為可重復讀或更高級別，或者在事務持續時間內用鎖定提示保留共享鎖。
2）更新鎖（U鎖）更新鎖是共享鎖和排他鎖的混合型鎖，更新鎖意味著在做一個更新時，一個共享鎖在掃描完成符合條件的數據後可能會轉化成排他鎖。這裡面有兩個步驟：（（1)掃描獲取Where條件時，這部分是一個更新查詢，此時是一個更新鎖。
（2）如果將執行寫入更新，此時該鎖升級到排他鎖；否則，該鎖轉變成共享鎖。
3）排他鎖（X鎖）排他鎖可以防止並發事務對資源進行訪問，不與其他任何鎖兼容。使用排他鎖時，任何其他事務都無法修改數據；僅在未提交讀隔離級別時才會被其他事務讀取佔有的數據資源。
2.死鎖死鎖是指兩個或兩個以上的進程在執行過程中，由於競爭資源或者彼此通信而造成的一種阻塞的現象，若無外力作用，它們將無法推進下去，此時稱系統處於死鎖狀態或系統產生了死鎖。這些永遠在互相等待的進程稱為死鎖進程。下面從死鎖產生的原因、條件及預防措施等方面來研究事務的死鎖。
（1)死鎖產生的原因當兩個或多個進程各自具有某個資源的鎖定，但其他進程嘗試要鎖定此資源，而造成進程永久封鎖彼此時，會發生死鎖。例如，事務A取得數據列1的排他鎖定，事務B取得數據列2的排他鎖定，事務A現在要求取得數據列2的獨占鎖定，事務B現在要求取得數據列1的獨占鎖定。事務A與事務B均需要獨占數據列1與數據列2的資源，但兩個資源分別被兩個事務各佔一個，互相等待對方的占據的資源才能完成本身的事務，就會造成事務間進程的死鎖。
2）死鎖產生的條件雖然進程在運行過程中可能發生死鎖，但死鎖的發生也必須具備一定的條件。死鎖的發生必須具備以下四個必要條件。
（（1)互斥條件。互斥條件指進程對所分配到的資源進行排他性使用，即在一段時間內某資源只由一個進程佔用。如果此時還有其他進程請求資源，則請求者只能等待，直至佔有資源的進程用完釋放。
（2）請求和保持條件。請求和保持條件指進程已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其他進程佔有，此時請求進程阻塞，但又對自己已獲得的其他資源保持不放。
（3）不剝奪條件。不剝奪條件指進程已獲得的資源在未使用完之前不能被剝奪，只能在使用完時由自己釋放。
（4）環路等待條件。環路等待條件指在發生死鎖時，必然存在一個進程——資源的環形鏈，即進程集合{P0，P1，P2，…，Pn}中的P0正在等待一個P1佔用的資源；P1正在等待P2佔用的資源；…；Pn正在等待已被P0佔用的資源。死鎖的預防措施理解了死鎖的原因，尤其是產生死鎖的四個必要條件，就可以最大可能地避免、預防和解除死鎖。只要打破四個必要條件之一就能有效預防死鎖的發生。
（（1)打破互斥條件。改造獨占性資源為虛擬資源，但大部分資源已無法改造。
（2）打破不可搶占條件。當一進程佔有一獨占性資源後又去申請另一獨占性資源而無法滿足時，則退出原佔有的資源。
（3）打破佔有且申請條件。採用資源預先分配策略，即進程運行前申請全部資源，滿足則運行，不滿足就等待，這樣就不會出現佔有部分資源後再去申請其他資源的場景。
（4）打破循環等待條件。實現資源有序分配策略，對所有設備實現分類編號，所有進程只能採用按序號遞增的形式申請資源。
所以，在系統設計、進程調度等方面要注意如何不讓這四個必要條件成立，如何確定資源的合理分配演算法，避免進程永久占據系統資源。此外，也要防止進程在處於等待狀態的情況下佔用資源，在系統運行過程中，對進程發出的每一個系統能夠滿足的資源申請進行動態檢查，並根據檢查結果決定是否分配資源，若分配後系統可能發生死鎖，則不予分配；否則予以分配。因此，對資源的分配要給予合理的規劃。
7. 怎麼理解資料庫的鎖 一般鎖分別哪幾種
資料庫是一個多用戶使用的共享資源。當多個用戶並發地存取數據時，在資料庫中就會產生多個事務同時存取同一數據的情況。若對並發操作不加控制就可能會讀取和存儲不正確的數據，破壞資料庫的一致性。
加鎖是實現資料庫並發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前，先向系統發出請求，對其加鎖。加鎖後事務就對該數據對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數據對象進行更新操作。
在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當數據對象被加上排它鎖時，其他的事務不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。
(7)資料庫事物鎖擴展閱讀：
排它鎖和共享鎖的不同之處：
1、共享鎖（S鎖）：如果事務T對數據A加上共享鎖後，則其他事務只能對A再加共享鎖，不能加排他鎖。獲准共享鎖的事務只能讀數據，不能修改數據。
排他鎖（X鎖）：如果事務T對數據A加上排他鎖後，則其他事務不能再對A加任任何類型的封鎖。獲准排他鎖的事務既能讀數據，又能修改數據。
2、共享鎖下其它用戶可以並發讀取，查詢數據。但不能修改，增加，刪除數據，資源共享。
3、共享鎖又稱為讀鎖（Share lock,簡記為S鎖），若事務T對數據對象A加上S鎖，則其它事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。
8. 關於資料庫事務與加鎖
由於並發操作的存在，引出了隔離級。
由於對資源存在競爭，引出了鎖。
不同的隔離級別，區別在於鎖的釋放時機不同。
具體選擇何種隔離級別，要根據實際應用的需求。一般情況下，使用系統默認的 讀提交 即可滿足需求。
9. 資料庫中,鎖有哪幾種類型,分別表示什麼涵義什麼是兩段領協議
摘要 兩段鎖協議：是指所有的事務必須分兩個階段對數據項加鎖和解鎖。即事務分兩個階段，第一個階段是獲得封鎖。事務可以獲得任何數據項上的任何類型的鎖，但是不能釋放；第二階段是釋放封鎖，事務可以釋放任何數據項上的任何類型的鎖，但不能申請。