本文目錄一覽：
北大青鳥java培訓：在Java程序中處理資料庫超時與死鎖？
每個使用關係型資料庫的程序都可能遇到數據死鎖或不可用的情況，而這些情況需要在代碼中編程來解決;本文主要介紹與資料庫事務死鎖等情況相關的重試邏輯概念，此外，還會探討如何避免死鎖等問題，文章以DB2(版本9)與為例進行講解。
什麼是資料庫鎖定與死鎖鎖定(Locking)發生在當一個事務獲得對某一資源的「鎖」時，這時，其他的事務就不能更改這個資源了，這種機制的存在是為了保證數據一致性;在設計與資料庫交互的程序時，必須處理鎖與資源不可用的情況。
鎖定是個比較複雜的概念，仔細說起來可能又需要一大篇，所以在本文中，只把鎖定看作是一個臨時事件，這意味著如果一個資源被鎖定，它總會在以後某個時間被釋放。
而死鎖發生在當多個進程訪問同一資料庫時，其中每個進程擁有的鎖都是其他進程所需的，由此造成每個進程都無法繼續下去。
如何避免鎖我們可利用事務型資料庫中的隔離級別機制來避免鎖的創建，正確地使用隔離級別可使程序處理更多的並發事件(如允許多個用戶訪問數據)，還能預防像丟失修改(LostUpdate)、讀「臟」數據(DirtyRead)、不可重複讀(NonrepeatableRead)及「虛」(Phantom)等問題。
隔離級別問題現象丟失修改讀「臟」數據不可重複讀「虛」可重複讀取NoNoNoNo讀取穩定性NoNoNoYes游標穩定性NoNoYesYes未提交的讀NoYesYesYes表1：DB2的隔離級別與其對應的問題現象在只讀模式中，就可以防止鎖定發生，而不用那些未提交只讀隔離級別的含糊語句。
山西電腦培訓發現一條SQL語句當使用了下列命令之一時，就應該考慮只讀模式了
北大青鳥java培訓：如何避免死鎖？
什麼是死鎖，如何避免死鎖？線程A需要資源X，而線程B需要資源Y，而雙方都掌握有對方所要的資源，這種情況稱為死鎖（deadlock），或死亡擁抱（thedeadlyembrace）。
在並發程序設計中，江西電腦培訓建議死鎖(deadlock)是一種十分常見的邏輯錯誤。
通過採用正確的編程方式，死鎖的發生不難避免。
死鎖的四個必要條件在計算機專業的教材中，通常都會介紹死鎖的四個必要條件。
這四個條件缺一不可，或者說只要破壞了其中任何一個條件，死鎖就不可能發生。
我們來複習一下，這四個條件是：互斥（Mutualexclusion）：存在這樣一種資源，它在某個時刻只能被分配給一個執行緒（也稱為線程）使用；持有（Holdandwait）：當請求的資源已被佔用從而導致執行緒阻塞時，資源佔用者不但無需釋放該資源，而且還可以繼續請求更多資源；不可剝奪（Nopreemption）：執行緒獲得到的互斥資源不可被強行剝奪，換句話說，只有資源佔用者自己才能釋放資源；環形等待（Circularwait）：若干執行緒以不同的次序獲取互斥資源，從而形成環形等待的局面，想像在由多個執行緒組成的環形鏈中，每個執行緒都在等待下一個執行緒釋放它持有的資源。
解除死鎖的必要條件不難看出，在死鎖的四個必要條件中，第二、三和四項條件比較容易消除。
通過引入事務機制，往往可以消除第二、三兩項條件，方法是將所有上鎖操作均作為事務對待，一旦開始上鎖，即確保全部操作均可回退，同時通過鎖管理器檢測死鎖，並剝奪資源（回退事務）。
這種做法有時會造成較大開銷，而且也需要對上鎖模式進行較多改動。
消除第四項條件是比較容易且代價較低的辦法。
具體來說這種方法約定：上鎖的順序必須一致。
具體來說，我們人為地給鎖指定一種類似「水位」的方向性屬性。
無論已持有任何鎖，該執行緒所有的上鎖操作，必須按照一致的先後順序從低到高（或從高到低）進行，且在一個系統中，只允許使用一種先後次序。
請注意，放鎖的順序並不會導致死鎖。
也就是說，儘管按照鎖A,鎖B,放A,放B這樣的順序來進行鎖操作看上去有些怪異，但是只要大家都按先A後B的順序上鎖，便不會導致死鎖。
解決方法：1使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務（細化處理邏輯，執行一段邏輯後便回滾或者提交，然後再執行其它邏輯，直到事物執行完畢提交）；2設置死鎖超時參數為合理範圍，如：3分鐘-10分種；超過時間，自動放棄本次操作，避免進程懸掛； 3優化程序，檢查並避免死鎖現象出現； 4對所有的腳本和SP都要仔細測試，在正是版本之前。
5所有的SP都要有錯誤處理（通過@error） 6一般不要修改SQLSERVER事務的默認級別。
不推薦強行加鎖另外參考的解決方法：按同一順序訪問對象如果所有並發事務按同一順序訪問對象，則發生死鎖的可能性會降低。
例如，如果兩個並發事務獲得Supplier表上的鎖，然後獲得Part表上的鎖，則在其中一個事務完成之前，另一個事務被阻塞在Supplier表上。
第一個事務提交或回滾後，第二個事務繼續進行。
不發生死鎖。
將存儲過程用於所有的數據修改可以標準化訪問對象的順序。
java 死鎖
死鎖
死鎖是這樣一種情形：多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由於線程被無限期地阻塞，因此程序不可能正常終止。
導致死鎖的根源在於不適當地運用「synchronized」關鍵詞來管理線程對特定對象的訪問。「synchronized」關鍵詞的作用是，確保在某個時刻只有一個線程被允許執行特定的代碼塊，因此，被允許執行的線程首先必須擁有對變數或對象的排他性的訪問權。當線程訪問對象時，線程會給對象加鎖，而這個鎖導致其它也想訪問同一對象的線程被阻塞，直至第一個線程釋放它加在對象上的鎖。
由於這個原因，在使用「synchronized」關鍵詞時，很容易出現兩個線程互相等待對方做出某個動作的情形。代碼一是一個導致死鎖的簡單例子。
//代碼一
class Deadlocker {
int field_1;
private Object lock_1 = new int[1];
int field_2;
private Object lock_2 = new int[1];
public void method1(int value) {
「synchronized」 (lock_1) {
「synchronized」 (lock_2) {
field_1 = 0; field_2 = 0;
}
}
}
public void method2(int value) {
「synchronized」 (lock_2) {
「synchronized」 (lock_1) {
field_1 = 0; field_2 = 0;
}
}
}
}
參考代碼一，考慮下面的過程：
◆ 一個線程（ThreadA）調用method1()。
◆ ThreadA在lock_1上同步，但允許被搶先執行。
◆ 另一個線程（ThreadB）開始執行。
◆ ThreadB調用method2()。
◆ ThreadB獲得lock_2，繼續執行，企圖獲得lock_1。但ThreadB不能獲得lock_1，因為ThreadA佔有lock_1。
◆ 現在，ThreadB阻塞，因為它在等待ThreadA釋放lock_1。
◆ 現在輪到ThreadA繼續執行。ThreadA試圖獲得lock_2，但不能成功，因為lock_2已經被ThreadB佔有了。
◆ ThreadA和ThreadB都被阻塞，程序死鎖。
當然，大多數的死鎖不會這麼顯而易見，需要仔細分析代碼才能看出，對於規模較大的多線程程序來說尤其如此。好的線程分析工具，例如JProbe Threadalyzer能夠分析死鎖並指出產生問題的代碼位置。
隱性死鎖
隱性死鎖由於不規範的編程方式引起，但不一定每次測試運行時都會出現程序死鎖的情形。由於這個原因，一些隱性死鎖可能要到應用正式發布之後才會被發現，因此它的危害性比普通死鎖更大。下面介紹兩種導致隱性死鎖的情況：加鎖次序和佔有並等待。
加鎖次序
當多個並發的線程分別試圖同時佔有兩個鎖時，會出現加鎖次序衝突的情形。如果一個線程佔有了另一個線程必需的鎖，就有可能出現死鎖。考慮下面的情形，ThreadA和ThreadB兩個線程分別需要同時擁有lock_1、lock_2兩個鎖，加鎖過程可能如下：
◆ ThreadA獲得lock_1；
◆ ThreadA被搶佔，VM調度程序轉到ThreadB；
◆ ThreadB獲得lock_2；
◆ ThreadB被搶佔，VM調度程序轉到ThreadA；
◆ ThreadA試圖獲得lock_2，但lock_2被ThreadB佔有，所以ThreadA阻塞；
◆ 調度程序轉到ThreadB；
◆ ThreadB試圖獲得lock_1，但lock_1被ThreadA佔有，所以ThreadB阻塞；
◆ ThreadA和ThreadB死鎖。
必須指出的是，在代碼絲毫不做變動的情況下，有些時候上述死鎖過程不會出現，VM調度程序可能讓其中一個線程同時獲得lock_1和lock_2兩個鎖，即線程獲取兩個鎖的過程沒有被中斷。在這種情形下，常規的死鎖檢測很難確定錯誤所在。
佔有並等待
如果一個線程獲得了一個鎖之後還要等待來自另一個線程的通知，可能出現另一種隱性死鎖，考慮代碼二。
//代碼二
public class queue {
static java.lang.Object queueLock_;
Producer producer_;
Consumer consumer_;
public class Producer {
void produce() {
while (!done) {
「synchronized」 (queueLock_) {
produceItemAndAddItToQueue();
「synchronized」 (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
「synchronized」 (queueLock_) {
「synchronized」 (consumer_) {
consumer_.wait();
}
removeItemFromQueueAndProcessIt();
}
}
}
}
}
}
在代碼二中，Producer向隊列加入一項新的內容後通知Consumer，以便它處理新的內容。問題在於，Consumer可能保持加在隊列上的鎖，阻止Producer訪問隊列，甚至在Consumer等待Producer的通知時也會繼續保持鎖。這樣，由於Producer不能向隊列添加新的內容，而Consumer卻在等待Producer加入新內容的通知，結果就導致了死鎖。
在等待時佔有的鎖是一種隱性的死鎖，這是因為事情可能按照比較理想的情況發展—Producer線程不需要被Consumer佔據的鎖。儘管如此，除非有絕對可靠的理由肯定Producer線程永遠不需要該鎖，否則這種編程方式仍是不安全的。有時「佔有並等待」還可能引發一連串的線程等待，例如，線程A佔有線程B需要的鎖並等待，而線程B又佔有線程C需要的鎖並等待等。
要改正代碼二的錯誤，只需修改Consumer類，把wait()移出「synchronized」()即可。
java的死鎖是什麼，如何避免死鎖
我們先看看這樣一個生活中的例子：在一條河上有一座橋，橋面較窄，只能容納一輛汽車通過，無法讓兩輛汽車並行。如果有兩輛汽車A和B分別由橋的兩端駛上該橋，則對於A車來說，它走過橋面左面的一段路（即佔有了橋的一部分資源），要想過橋還須等待B車讓出右邊的橋面，此時A車不能前進；對於B車來說，它走過橋面右邊的一段路（即佔有了橋的一部分資源），要想過橋還須等待A車讓出左邊的橋面，此時B車也不能前進。兩邊的車都不倒車，結果造成互相等待對方讓出橋面，但是誰也不讓路，就會無休止地等下去。這種現象就是死鎖。如果把汽車比做進程，橋面作為資源，那麽上述問題就描述為：進程A佔有資源R1，等待進程B佔有的資源Rr；進程B佔有資源Rr，等待進程A佔有的資源R1。而且資源R1和Rr只允許一個進程佔用，即：不允許兩個進程同時佔用。結果，兩個進程都不能繼續執行，若不採取其它措施，這種循環等待狀況會無限期持續下去，就發生了進程死鎖。
在計算機系統中，涉及軟體，硬體資源都可能發生死鎖。例如：系統中只有一台CD-ROM驅動器和一台印表機，某一個進程佔有了CD-ROM驅動器，又申請印表機；另一進程佔有了印表機，還申請CD-ROM。結果，兩個進程都被阻塞，永遠也不能自行解除。
所謂死鎖，是指多個進程循環等待它方佔有的資源而無限期地僵持下去的局面。很顯然，如果沒有外力的作用，那麽死鎖涉及到的各個進程都將永遠處於封鎖狀態。從上面的例子可以看出，計算機系統產生死鎖的根本原因就是資源有限且操作不當。即：一種原因是系統提供的資源太少了，遠不能滿足並發進程對資源的需求。這種競爭資源引起的死鎖是我們要討論的核心。例如：消息是一種臨時性資源。某一時刻，進程A等待進程B發來的消息，進程B等待進程C發來的消息，而進程C又等待進程A發來的消息。消息未到，A，B，C三個進程均無法向前推進，也會發生進程通信上的死鎖。另一種原因是由於進程推進順序不合適引發的死鎖。資源少也未必一定產生死鎖。就如同兩個人過獨木橋，如果兩個人都要先過，在獨木橋上僵持不肯後退，必然會應競爭資源產生死鎖；但是，如果兩個人上橋前先看一看有無對方的人在橋上，當無對方的人在橋上時自己才上橋，那麽問題就解決了。所以，如果程序設計得不合理，造成進程推進的順序不當，也會出現死鎖。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/240699.html
微信掃一掃 
支付寶掃一掃 