死锁不仅在个人学习中，甚至在开发中也并不常见。但是一旦出现死锁，后果将非常严重。
首先什么是死锁呢？打个比方，就好像有两个人打架，互相限制住了(锁住，抱住)彼此一样，互相动弹不得，而且互相欧气，你不松手我就不松手。好了谁也动弹不得。
在多线程的环境下，势必会对资源进行抢夺。当两个线程锁住了当前资源，但都需要对方的资源才能进行下一步操作，这个时候两方就会一直等待对方的资源释放。这就形成了死锁。这些永远在互相等待的进程称为死锁进程。
那么我们来总结一下死锁产生的条件：
互斥:资源的锁是排他性的，加锁期间只能有一个线程拥有该资源。其他线程只能等待锁释放才能尝试获取该资源。
请求和保持:当前线程已经拥有至少一个资源，但其同时又发出新的资源请求，而被请求的资源被其他线程拥有。此时进入保持当前资源并等待下个资源的状态。
不剥夺：线程已拥有的资源，只能由自己释放，不能被其他线程剥夺。
循环等待：是指有多个线程互相的请求对方的资源，但同时拥有对方下一步所需的资源。形成一种循环，类似2)请求和保持。但此处指多个线程的关系。并不是指单个线程一直在循环中等待。
什么？还是不理解？那我们直接上代码，动手写一个死锁。
二、写一个死锁根据条件，我们让两个线程互相请求保持。
/**
* 模拟死锁场景
*/
public class DeadLockDemo implements Runnable{
public static int flag = 1;
//static 变量是 类对象共享的
static Object o1 = new Object();
static Object o2 = new Object();
@Override
public void run() {
System.out.println(Thread.currentThread().getName() "：此时 flag = " flag);
if(flag == 1){
synchronized (o1){
try {
System.out.println("我是" Thread.currentThread().getName() "锁住 o1");
Thread.sleep(3000);
System.out.println(Thread.currentThread().getName() "醒来->准备获取 o2");
}catch (Exception e){
e.printStackTrace();
}
synchronized (o2){
System.out.println(Thread.currentThread().getName() "拿到 o2");//第24行
}
}
}
if(flag == 0){
synchronized (o2){
try {
System.out.println("我是" Thread.currentThread().getName() "锁住 o2");
Thread.sleep(3000);
System.out.println(Thread.currentThread().getName() "醒来->准备获取 o1");
}catch (Exception e){
e.printStackTrace();
}
synchronized (o1){
System.out.println(Thread.currentThread().getName() "拿到 o1");//第38行
}
}
}
}
public static void main(String args[]){
DeadLockDemo t1 = new DeadlockDemo();
DeadLockDemo t2 = new DeadLockDemo();
t1.flag = 1;
new Thread(t1).start();
//让main线程休眠1秒钟,保证t2开启锁住o2.进入死锁
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
t2.flag = 0;
new Thread(t2).start();
}
代码中，
t1创建，t1先拿到o1的锁，开始休眠3秒。然后
t2线程创建，t2拿到o2的锁，开始休眠3秒。然后
t1先醒来，准备拿o2的锁，发现o2已经加锁，只能等待o2的锁释放。
t2后醒来，准备拿o1的锁，发现o1已经加锁，只能等待o1的锁释放。
t1,t2形成死锁。
我们查看运行状态
我们利用jdk提供的工具定位死锁问题：
jps显示所有当前java虚拟机进程名及pid.
jstack打印进程堆栈信息。
列出所有java进程。
我们检查一下DeadLockDemo，为什么这个线程不退栈。
jstack 11170
我们直接翻到最后:已经检测出了一个java级别死锁。其中两个线程分别卡在了代码第27行和第41行。检查我们代码的对应位置，即可排查错误。此处我们是第二个锁始终拿不到，所以死锁了。
在这里插播一下，还是有很多朋友对死锁不了解，为了让大家在之后的学习或者工作中避免出现死锁不知道该如何解决。我在这里写一些常见的死锁是怎么产生的便于大家避免，遇到相似的情况可以很好的解决。后续也会持续更新Java的其它知识点和面试方法资料等等...感兴趣的铁汁们可以持续关注我
常见的死锁是如何产生的，如何避免概述：什么场景下回发生 00060 死锁问题： 一般情况下，数据库自身发生死锁的情况很少，一般情况都是因为应用本身调用问题导致的 00060异常 。
比如说有两个会话sid，分别为 138 和136，这两个会话都要对 6677 和 7788 两个人加工资，但是执行的顺序不一样，操作分别是：
-- 会话session号 Session 1 (sid = 136)， Session 2 (sid = 138)
-- 执行的语句 Session 1 (sid = 136)
update emp set sal=sal 100 where empno=6677;
update emp set sal=sal 100 where empno=7788;
-- 执行的语句 Session 2 (sid = 138)
update emp set sal=sal 100 where empno=7788;
update emp set sal=sal 100 where empno=6677;
ORA-00060:deadlock detected while waiting for resource这样我们就成功的触发了一个ORA-00060。
出现这个问题，我们可以查看Oracle日志，日志路径：$ORACLE_BASE/diag/rdbms/org11/ora11/trace/alert*.log
可以从告警日志中看到很多类似如下的日志：
ORA-00060:Deadlock detected.More info in file
ORA-00060:Deadlock detected.More info in file /home1/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_14757.trc
我们看下对饮的trc日志，主要看Deadlock graph，其中：可以看到136和138互相死锁，session 138（也就是 session2，sid=138）等着要 ROWID=AAAMfAAAAgAAA的行锁，而 session136（也就是 session1，sid=136）等着要ROWID=AAAMfPAAEAAAAgAAL 的行。
处理方式：1. 给资源编号，然后按照固定的顺序进行访问。 简单的来说，就是先改编号小的，在改编号大的。当然，反着来也可以。
-- 会话session号 Session 1 (sid = 136)， Session 2 (sid = 138)
update emp set sal=sal 100 where empno=6677;
update emp set sal=sal 100 where empno=7788;
Waiting...
update emp set sal=sal 100 where empno=7788;
commit/rollback;
update emp set sal=sal 100 where empno=6677;
在这里，工资增加两次，但是 session 2 被 session 1 阻塞了，对于用户体验来说，感受不好。
如果 session 1 一直不结束事务，session 2 只能一直等下去，这样比deadlock 后，Oracle 程序本身出面调停还要糟糕。
2. 可以在 select … for update nowait 语句测试一下需要更改的行是否被锁定 如果没有被锁定，那这个语句会马上给这行加锁，如果已经加锁那就马上返回：ORA-00054:resource busy and acquire with NOWAIT specified ，如下表所示：
-- 会话session号 Session 1 (sid = 136)， Session 2 (sid = 138)
select * from emp where empno in(6677,7788) for update nowait;
select * from emp where empno in(6677,7788) for update nowait;
ORA-00054:resource busy and acquire with NOWAIT specified
update emp set sal=sal 100 where empno=6677;
update emp set sal=sal 100 where empno=7788;
方法一和方法二都存在一定的问题，特别是在ND代码中如果使用方法二那么修改起来工作量太大，但是如果我们不处理，Oracle有自动检测死锁并且回滚事务的功能，也就是说之前的会话中136 和138 有一个会成功，一个会回滚，返回失败，这样就保证了数据的一致性。
总结：对应上面两处处理方式。感觉都不好，毕竟现网这种场景较少。而且这种死锁不是永久性的一直卡死在这，Oracle会检测到这种死锁的，并且检测到后会自己回滚，所以直接交给Oracle即可。
附相关的查询SQL：1.查询死锁：
select t2.username,t2.sid,t2.seria#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id = t2.sid
order by t2.logon_time;
2.根据 sid 查询对应的SQL语句，比如第一点查询出 sid 为136 和138 的死锁结果：
select sql_text
from v$session a,$sqltext_with_newlines b
where DECODE(a.sql_hash_value,0,prev_hash_value,sql_hash_value) = b.hash_value and a.sid in ('136','138')
order by piece;
3.查看处于等待状态的SQL语句：
select a.spid,c.EVENT,b.LOGON_TIME,d.SQL_TEXT,a.PROGRAM
from v$process a,v$session b,v$session_wait c,v$sql d
where a.ADDR = b.PADDR and b.SID = c.SID
and b.SQL_HASH_VALUE = D.HASH_VALUE
and c.EVENT NOT LIKE '%SQL*Net%'
and c.EVENT NOT LIKE '%smon%'
and c.EVENT NOT LIKE '%jopq%'
and c.EVENT NOT LIKE '%ipc%'
4.查看目前是否有“长时间持有锁未释放”，必要的情况下可以用对应的 command 杀死 session：
select I.BLOCK,ILMODE,I.REQUEST,I.TYPE,I.ID1,I.CTIME,s.SID,s.SERIAL#,
T.SQL_TEXT,p.SPID,'ALTER SYSTEM KILL SESSION'"||S.SID||','||s.serial#||"',' Command
from v$lock i,v$SESSION s,v$SQL t,v$process p
where I.ID1 in (select id1 from v$lock where block = 1)
and I.SID = s.SID and (t.hash_value = DECODE(s.sql_hash_value,0,s.prev_hash_value,s.sql_hash_value))
and t.address = DECODE(a.sql_hash_value,0,s.prev_hash_addr,s.sql_address))
and p.ADDR = s.PADDR
order by I.ID1,I.CTIME desc;
5.杀死进程（396为sid，60589为serial#），该条可以结合第一点进行：
alter system kill session '396,60589';
死锁一旦发生，我们就无法解决了。所以我们只能避免死锁的发生。既然死锁需要满足四种条件，那我们就从条件下手，只要打破任意规则即可。
（互斥）尽量少用互斥锁，能加读锁，不加写锁。当然这条无法避免。（请求和保持）采用资源静态分配策略（进程资源静态分配方式是指一个进程在建立时就分配了它需要的全部资源）.我们尽量不让线程同时去请求多个锁，或者在拥有一个锁又请求不到下个锁时，不保持等待，先释放资源等待一段时间在重新请求。（不剥夺）允许进程剥夺使用其他进程占有的资源。优先级。（循环等待）尽量调整获得锁的顺序，不发生嵌套资源请求。加入超时。
本文到此结束啦，喜欢的铁子们可以点点赞和关注， 文章持续更新，也可以评论出你想看哪一块技术。铁子们的支持是我的动力，创作离不开铁子们的支持，在此先感谢大家！
,
