㈠ 什麼是活鎖什麼是死鎖在事務調度中，如何預防和解決死鎖
1.
活鎖：數據資源釋放時間不確定，導致某些事務長時間等待，得不到封鎖的機會
死鎖：多個事務各自佔有部分資源等待另一部分資源，資源需求出現迴路，導致事務停頓得不到執行
解決活鎖：先來先服務
解決死鎖：預防：一次封鎖法、順序封鎖法
診斷並解除：超時法、等待圖法
㈡ 資料庫阻塞和死鎖的區別
阻塞只是因為事務沒有執行完成而鎖住相關的資源而導致其它事務不能訪問被鎖住的資源。
死鎖是這樣：
事務1 先請求 A，再請求B
事務2 先請求B，再請求A 這樣，就會造成死鎖
㈢ 資料庫中死鎖是什麼產生的
資料庫操作的死鎖是不可避免的，本文並不打算討論死鎖如何產生，重點在於解決死鎖，通過SQL Server 2005, 現在似乎有了一種新的解決辦法。
將下面的SQL語句放在兩個不同的連接裡面，並且在5秒內同時執行，將會發生死鎖。
use Northwind
begin tran
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
print @#end tran@#
SQL Server對付死鎖的辦法是犧牲掉其中的一個，拋出異常，並且回滾事務。在SQL Server 2000，語句一旦發生異常，T-SQL將不會繼續運行，上面被犧牲的連接中， print @#end tran@#語句將不會被運行，所以我們很難在SQL Server 2000的T-SQL中對死鎖進行進一步的處理。
現在不同了，SQL Server 2005可以在T-SQL中對異常進行捕獲，這樣就給我們提供了一條處理死鎖的途徑：
下面利用的try ... catch來解決死鎖。
SET XACT_ABORT ON
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
解決方法當然就是重試，但捕獲錯誤是前提。rollback後面的waitfor不可少，發生沖突後需要等待一段時間，@retry數目可以調整以應付不同的要求。
但是現在又面臨一個新的問題: 錯誤被掩蓋了，一但問題發生並且超過3次，異常卻不會被拋出。SQL Server 2005 有一個RaiseError語句，可以拋出異常，但卻不能直接拋出原來的異常，所以需要重新定義發生的錯誤，現在，解決方案變成了這樣:
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
if ERROR_NUMBER() <> 0
begin
declare @ErrorMessage nvarchar(4000);
declare @ErrorSeverity int;
declare @ErrorState int;
select
@ErrorMessage = ERROR_MESSAGE(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE();
raiserror (@ErrorMessage,
@ErrorSeverity,
@ErrorState
);
end
㈣ java多線程中的死鎖，活鎖，飢餓，無鎖都是什麼鬼
死鎖發生在當一些進程請求其它進程佔有的資源而被阻塞時。
另外一方面，活鎖不會被阻塞，而是不停檢測一個永遠不可能為真的條件。除去進程本身持有的資源外，活鎖狀態的進程會持續耗費寶貴的CPU時間。
最後，進程會處於飢餓狀態是因為持續地有其它優先順序更高的進程請求相同的資源。不像死鎖或者活鎖，飢餓能夠被解開。例如，當其它高優先順序的進程都終止時並且沒有更高優先順序的進程到達。
㈤ 死鎖的概念
謂死鎖：
是指兩個或兩個以上的進程在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。
由於資源佔用是互斥的，當某個進程提出申請資源後，使得有關進程在無外力協助下，永遠分配不到必需的資源而無法繼續運行，這就產生了一種特殊現象：死鎖。」
望樓主採納！！！
㈥ 死鎖的概述
死鎖的規范定義：集合中的每一個進程都在等待只能由本集合中的其他進程才能引發的事件，那麼該組進程是死鎖的。
一種情形，此時執行程序中兩個或多個線程發生永久堵塞（等待），每個線程都在等待被其他線程佔用並堵塞了的資源。例如，如果線程A鎖住了記錄1並等待記錄2，而線程B鎖住了記錄2並等待記錄1，這樣兩個線程就發生了死鎖現象。
計算機系統中，如果系統的資源分配策略不當，更常見的可能是程序員寫的程序有錯誤等，則會導致進程因競爭資源不當而產生死鎖的現象。
在兩個或多個任務中，如果每個任務鎖定了其他任務試圖鎖定的資源，此時會造成這些任務永久阻塞，從而出現死鎖。例如：事務A 獲取了行 1 的共享鎖。事務 B 獲取了行 2 的共享鎖。
排他鎖，等待事務 B 完成並釋放其對行 2 持有的共享鎖之前被阻塞。
排他鎖，等待事務 A 完成並釋放其對行 1 持有的共享鎖之前被阻塞。
事務 B 完成之後事務 A 才能完成，但是事務 B 由事務 A 阻塞。該條件也稱為循環依賴關系：事務 A 依賴於事務 B，事務 B 通過對事務 A 的依賴關系關閉循環。
除非某個外部進程斷開死鎖，否則死鎖中的兩個事務都將無限期等待下去。Microsoft SQL Server 資料庫引擎死鎖監視器定期檢查陷入死鎖的任務。如果監視器檢測到循環依賴關系，將選擇其中一個任務作為犧牲品，然後終止其事務並提示錯誤。這樣，其他任務就可以完成其事務。對於事務以錯誤終止的應用程序，它還可以重試該事務，但通常要等到與它一起陷入死鎖的其他事務完成後執行。
在應用程序中使用特定編碼約定可以減少應用程序導致死鎖的機會。有關詳細信息，請參閱將死鎖減至最少。
死鎖經常與正常阻塞混淆。事務請求被其他事務鎖定的資源的鎖時，發出請求的事務一直等到該鎖被釋放。默認情況下，除非設置了 LOCK_TIMEOUT，否則 SQL Server 事務不會超時。因為發出請求的事務未執行任何操作來阻塞擁有鎖的事務，所以該事務是被阻塞，而不是陷入了死鎖。最後，擁有鎖的事務將完成並釋放鎖，然後發出請求底事務將獲取鎖並繼續執行。
死鎖有時稱為抱死。
不只是關系資料庫管理系統，任何多線程系統上都會發生死鎖，並且對於資料庫對象的鎖之外的資源也會發生死鎖。例如，多線程操作系統中的一個線程要獲取一個或多個資源（例如，內存塊）。如果要獲取的資源當前為另一線程所擁有，則第一個線程可能必須等待擁有線程釋放目標資源。這就是說，對於該特定資源，等待線程依賴於擁有線程。在資料庫引擎實例中，當獲取非資料庫資源（例如，內存或線程）時，會話會死鎖。
在示例中，對於 Part表鎖資源，事務 T1 依賴於事務 T2。同樣，對於 Supplier表鎖資源，事務 T2 依賴於事務 T1。因為這些依賴關系形成了一個循環，所以在事務 T1 和事務 T2 之間存在死鎖。
當表進行了分區並且 ALTER TABLE 的 LOCK_ESCALATION 設置設為 AUTO 時也會發生死鎖。當 LOCK_ESCALATION 設為 AUTO 時，通過允許資料庫引擎在 HoBT 級別而不是 TABLE 級別鎖定表分區會增加並發情況。但是，當單獨的事務在某個表中持有分區鎖並希望在其他事務分區上的某處持有鎖時，會導致發生死鎖。通過將 LOCK_ESCALATION 設為 TABLE 可以避免這種類型的死鎖，但此設置會因強制某個分區的大量更新以等待某個表鎖而減少並發情況。
㈦ 資料庫阻塞和死鎖的區別
資料庫阻塞的現象：第一個連接佔有資源沒有釋放，而第二個連接需要獲取這個資源。如果第一個連接沒有提交或者回滾，
第二個連接會一直等待下去，直到第一個連接釋放該資源為止。對於阻塞，資料庫無法處理，所以對資料庫操作要及時地提交或
者回滾。
資料庫死鎖的現象：第一個連接佔有資源沒有釋放，准備獲取第二個連接所佔用的資源，而第二個連接佔有資源沒有釋放，
准備獲取第一個連接所佔用的資源。這種互相佔有對方需要獲取的資源的現象叫做死鎖。對於死鎖，資料庫處理方法：犧牲一個
連接，保證另外一個連接成功執行
㈧ 什麼是「死鎖」和「飢餓」
死鎖： 可以認為是兩個線程或進程在請求對方佔有的資源。
飢餓：一個線程在無限地等待另外兩個或多個線程相互傳遞使用並且用不會釋放的資源。
出現以下四種情況會產生死鎖：
1，相互排斥。一個線程或進程永遠佔有共享資源，比如，獨占該資源。
2，循環等待。例如，進程A在等待進程B，進程B在等待進程C，而進程C又在等待進程A。
3，部分分配。資源被部分分配，例如，進程A和B都需要訪問一個文件，同時需要用到列印機，進程A得到了這個文件資源，進程B得到了列印機資源，但兩個進程都不能獲得全部的資源了。
4，缺少優先權。一個進程獲得了該資源但是一直不釋放該資源，即使該進程處於阻塞狀態。
(8)資料庫活鎖和死鎖的概念擴展閱讀
死鎖和活鎖的區別：活鎖和死鎖很像似。 只是活鎖的狀態可以發生改變。不過雖然狀態可以改變，卻沒有實質的進展。比如兩個人在一個很宅的胡同里。 一次只能並排過兩個人。 兩人比較禮貌，都要給對方讓路。 結果一起要麼讓到左邊，要麼讓到右邊，結果仍然是誰也過不去。 類似於原地踏步或者震盪狀態。
活鎖一般是由於對死鎖的不正確處理引起的。由於處於死鎖中的多個線程同時採取了行動。 而避免的方法也是只讓一個線程釋放資源。
㈨ 資料庫死鎖的基本解釋
每個使用關系型資料庫的程序都可能遇到數據死鎖
的情況。理解什麼是死鎖之前先要了解鎖定的概念：
多數情況下，可以認為如果一個資源被鎖定，它總會在以後某個時間被釋放。而死鎖發生在當多個進程訪問同一資料庫時，其中每個進程擁有的鎖都是其他進程所需的，由此造成每個進程都無法繼續下去。簡單的說，進程A等待進程B釋放他的資源，B又等待A釋放他的資源，這樣就互相等待就形成死鎖。