資料庫阻塞和死鎖在程式開發過程經常出現，怎麼樣避免呢？下面通過demo簡單模擬下，資料庫發生阻塞和死鎖的現象：
一、資料庫阻塞：
資料庫阻塞的現象：第乙個連線占有資源沒有釋放，而第二個連線需要獲取這個資源。如果第乙個連線沒有提交或者回滾，
第二個連線會一直等待下去，直到第乙個連線釋放該資源為止。對於阻塞，資料庫無法處理，所以對資料庫操作要及時地提交或
者回滾。
demo:
--建立表
create table tb(id int,createtime date);
--插入測試資料
insert into tb select 1,sysdate from dual;
insert into tb select 2,sysdate from dual;
insert into tb select 3,sysdate from dual;
commit;
第乙個連線，不提交或者回滾：
sql> update tb set id=2 where id=1;
1 row updated
第二個連線，一直在執行：
sql> update tb set id=2 where id=1;
因為第乙個連線占有tb表沒有釋放資源，而第二個連線一直在等待第乙個連線釋放該資源。
二、資料庫死鎖：
資料庫死鎖的現象：第乙個連線占有資源沒有釋放，準備獲取第二個連線所占用的資源，而第二個連線占有資源沒有釋放，
準備獲取第乙個連線所占用的資源。這種互相占有對方需要獲取的資源的現象叫做死鎖。對於死鎖，資料庫處理方法：犧牲乙個
連線，保證另外乙個連線成功執行。
demo:
--建立測試表t1
create table t1(id int,createtime date);
insert into t1 select 1,sysdate from dual;
insert into t1 select 2,sysdate from dual;
insert into t1 select 3,sysdate from dual;
commit;
--建立測試表t2
create table t2(id int,createtime date);
insert into t2 select 1,sysdate from dual;
insert into t2 select 2,sysdate from dual;
insert into t2 select 3,sysdate from dual;
commit;
第乙個連線,在command視窗中執行：
begin
--先修改t1
update t1 set id=2
where id=1;
--等待20s
dbms_lock.sleep(20);
--再修改t2
update t2 set id=2
where id=1;
end;
/ 執行結果：
ora-00060: 等待資源時檢測到死鎖
ora-06512: 在 line 9
第二個連線：
begin
--先修改t2
update t2 set id=2
where id=1;
--等待20s
dbms_lock.sleep(20);
--再修改t1
update t1 set id=2
where id=1;
end;
/執行結果：
pl/sql procedure successfully completed
因為第乙個連線占有表t1，想要獲取表t2的資源，而第二個連線占有表t2,想要獲取表t1的資源，這種互相占有對方想要獲取的資
源，滿足死鎖現象。最後第乙個連線報異常退出，而第二個連線執行成功。
阻塞和死鎖
阻塞和死鎖是兩個不同的概念。舉個例子，現在有執行緒1和執行緒2，執行緒1占用了資源a，執行緒2占用了資源b。此時執行緒2需要使用資源a才能繼續，但是資源a被執行緒1所占用，那麼執行緒2只能等待資源a被執行緒1釋放掉，這種情況稱為執行緒2被阻塞。但是，如果此時執行緒1也許要資源b才能繼續，那麼兩個執行...
資料庫死鎖
1.死鎖的概念 死鎖是程序死鎖的簡稱，是由dijkstra於1965年研究銀行家演算法時首先提出來的。它是計算機作業系統乃至併發程式設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。我們先看看這樣乙個生活中的例子 在一條河上有一座橋，橋面較窄，只能容納一...
資料庫死鎖
資料庫在進行insert，update，delete這些更新操作的時候為了保證資料一致性都會使用排他鎖。乙個事務裡進行update操作，在事務結束之前 commit or rollback 排他鎖不會被釋放。因此在乙個事務裡update多條資料的時候執行順序就尤為重要，兩個併發事務中更新操作的執行順...