死锁是并发中常见的问题，在业务逻辑复杂，锁较多时发生死锁饿的概率极大。死锁产生的主要原因在于线程之间“死等”对方手里的锁。

案例：
package com.yc.uc.test;
class Resouces{
    private String lockA;
    private String lockB;

    public Resouces(String lockA, String lockB) {
        this.lockA = lockA;
        this.lockB = lockB;
    }

    public void test() throws InterruptedException {
        synchronized (lockA){
            System.out.println(Thread.currentThread().getName()+"已经获取"+lockA+"尝试获取"+lockB);
            Thread.sleep(2000);
            synchronized (lockB){
                System.out.println("两个锁都已获取！");
            }
        }
    }

}
/**
 * @Author Allen
 * @Date 2021/3/8 10:35 上午
 * @Version 1.0
 */
public class DeadLockDemo {

    public static void main(String[] args) {
        String lock1 = "lock1";
        String lock2 = "lock2";
        new Thread(()->{
            try {
                new Resouces(lock1,lock2).test();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();

        new Thread(()->{
            try {
                new Resouces(lock2,lock1).test();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();
    }

}


运行结果：
Thread-0已经获取lock1尝试获取lock2
Thread-1已经获取lock2尝试获取lock1
//阻塞，并未结束


死锁产生以后，线程阻塞，极为隐蔽，在一般情况下较难发现。
分析方法：

终端指令：jps（java+ps）在终端查看进程号
(base) mac@lzydeMacBook-Pro /etc % jps
1744 Launcher
2144 Jps

//找到可能产生死锁的 全类名
1745 DeadLockDemo

329 
559 


终端指令：jstack 1745
(base) mac@lzydeMacBook-Pro /etc % jstack 1745
2021-03-08 10:57:00
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode):

......

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at com.yc.uc.test.Resouces.test(DeadLockDemo.java:16)
        - waiting to lock <0x0000000795aa1468> (a java.lang.String)
        - locked <0x0000000795aa14a0> (a java.lang.String)
        at com.yc.uc.test.DeadLockDemo.lambda$main$1(DeadLockDemo.java:42)
        at com.yc.uc.test.DeadLockDemo$$Lambda$2/739498517.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at com.yc.uc.test.Resouces.test(DeadLockDemo.java:16)
        - waiting to lock <0x0000000795aa14a0> (a java.lang.String)
        - locked <0x0000000795aa1468> (a java.lang.String)
        at com.yc.uc.test.DeadLockDemo.lambda$main$0(DeadLockDemo.java:34)
        at com.yc.uc.test.DeadLockDemo$$Lambda$1/1552787810.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.



可以查看到产生死锁的具体位置和对应的锁

Oracle删除死锁进程的方法。分享给大家供大家参考。具体如下：

步骤1：用以下SQL查看进程列表，判断出被锁定的表


复制代码 代码如下:

SELECT dob.OBJECT_NAME Table_Name,lo.SESSION_ID||', '||vss.SERIAL# 删除号,

lo.locked_mode,lo.SESSION_ID, vss.SERIAL#,vss.action Action,vss.osuser OSUSER, vss.LOGON_TIME,

vss.process AP_PID, VPS.SPID DB_PID ,vss.*

From v$locked_object lo, dba_objects dob, v$session vss, V$PROCESS VPS

Where lo.OBJECT_ID = dob.OBJECT_ID

and lo.SESSION_ID = vss.SID

AND VSS.paddr = VPS.addr

order by 2,3,DOB.object_name



查找被锁表

步骤2 删除进程，如之前的“删除号”查找出的结果为“286, 2184”，则运行以下SQL


复制代码 代码如下:

ALTER system kill session '286, 2184'



删除后不会马上生效一般,要过一会。



更多Java知识学习请访问Java免费学习   Java自学网 http://www.javalearns.com

关注微信号：javalearns  ，随时随地学Java

今天看到一个手机也能赚钱的网站，与大家分享（真实可信，已亲身体验）：

http://javalearns.jifenqiang.com/

1.首先我们需要判断是哪个用户锁住了哪张表.

1

2

3

–查询被锁表

select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName

from sys.dm_tran_locks where resource_type=‘OBJECT’

查询后会返回一个包含spid和tableName列的表.

其中spid是进程名,tableName是表名.

2.了解到了究竟是哪个进程锁了哪张表后,需要通过进程找到锁表的主机.

1

2

3

–查询主机名

exec sp_who2 ‘xxx’

xxx就是spid列的进程,检索后会列出很多信息,其中就包含主机名.

3.通过spid列的值进行关闭进程.

1

2

3

4

5

6

–关闭进程

declare @spid int

Set @spid = xxx --锁表进程

declare @sql varchar(1000)

set @sql='kill '+cast(@spid as varchar)

exec(@sql)

–关闭进程

declare @spid int

Set @spid = xxx --锁表进程

declare @sql varchar(1000)

set @sql='kill '+cast(@spid as varchar)

exec(@sql)

PS:有些时候强行杀掉进程是比较危险的,所以最好可以找到执行进程的主机,在该机器上关闭进程.

目录

一、死锁的四种必要条件

二、避免死锁的方法

2.1  死锁预防（确保不会进入死锁状态）

2.1.1 破坏不可剥夺条件

2.1.2  破坏请求与保持条件

2.1.3 破坏循环等待链条件

2.2  进程使用前判断-------只允许不会产生死锁的进程申请资源

2.2.1  什么是银行家算法

2.2.3 银行家算法设计的矩阵

2.2.4  具体例子

死锁概念：多个并发进程因争夺系统资源而产生相互等待的现象。

一、死锁的四种必要条件


1. 互斥：某种资源一次只允许一个进程访问，即该资源一旦分配给某个进程，其他进程就不能再访问，直到该进程访问结束。

2.不可剥夺：别人已经占有了某项资源，你不能因为自己也需要该资源，就去把别人的资源抢过来。

3. 请求与保持：一个进程本身占有资源（一种或多种），同时还有资源未得到满足，正在等待其他进程释放该资源。（即吃着碗里的，想着别人兜里）

4. 循环等待链：存在一个进程链，使得每个进程都占有下一个进程所需的至少一种资源。


当以上四个条件均满足，才会造成死锁，发生死锁的进程无法进行下去，它们所持有的资源也无法释放。这样会导致CPU的吞吐量下降。所以死锁情况是会浪费系统资源和影响计算机的使用性能的。

二、避免死锁的方法

2.1  死锁预防（确保不会进入死锁状态）

产生死锁需要四个条件，那么，只要这四个条件中至少有一个条件得不到满足，就不可能发生死锁了。由于互斥条件是非共享资源所必须的，不仅不能改变，还应加以保证，所以，主要是破坏产生死锁的其他三个条件。

2.1.1 破坏不可剥夺条件

当一个已经持有了一些资源的进程在提出新的资源请求没有得到满足时，它必须释放已经保持的所有资源，待以后需要使用的时候再申请。这就意味着已经占有的资源会被短暂地释放或者被其他进程抢占。

缺点：释放已经占有的资源有可能会导致进程之前的工作失效等。

2.1.2  破坏请求与保持条件

方法1：在进程开始前，必须一次性地申请其在整个运行过程中所需要的全部资源。

缺点：因某项资源不满足，而导致进程无法启动，这样的话，其他满足了的资源也不会得到利用，严重降低资源的利用率，造成资源浪费。（因为没手纸，占着茅坑不拉屎）

方法2：该方法是对第一种方法的改进，允许进程只获得运行初期需要的资源，便开始运行，在运行过程中逐步释放掉分配到的已经使用完毕的资源，然后再去请求新的资源。这样的话，资源利用率会得到提高

2.1.3 破坏循环等待链条件

可将每个资源编号，当一个进程占有编号为 i 的资源时，那么它下一次申请的资源只能申请编号大于 i  的资源。如下图：



缺点：这种方法是比较低效的。因为 资源的执行速度会变慢，具体为 例如 ：进程c（拥有资源3的进程）想要申请资源1，如果资源1并没有被其他进程占有，此时将它分配个进程c是没有问题的，但是为了避免产生循环等待，该申请会被拒绝，这样就降低了资源的利用率

 

2.2  进程使用前判断-------只允许不会产生死锁的进程申请资源

具体实现通常是银行家算法。

2.2.1  什么是银行家算法

银行家算法是一种最有代表性的避免死锁的算法。在避免死锁方法中允许进程动态地申请资源，但系统在进行资源分配之前，应先计算此次分配资源的安全性，若分配不会导致系统进入不安全状态，则分配，否则等待。

在银行中，客户申请贷款的数量是有限的，每个客户在第一次申请贷款时要声明完成该项目所需的最大资金量，在满足所有贷款要求时，客户应及时归还。银行家在客户申请的贷款数量不超过自己拥有的最大值时，都应尽量满足客户的需要。在这样的描述中，银行家就好比操作系统，资金就是资源，客户就相当于要申请资源的进程。



2.2.3 银行家算法设计的矩阵

为了实现银行家算法，在系统中必须设置这样四个数据结构，分别用来描述  系统中可利用的资源、所有进程对资源的最大需求、系统中的资源分配，以及所有进程还需要多少资源的情况。


(1) 可利用资源向量 Available。这是一个含有 m 个元素的数组，其中的每一个元素代表一类可利用的资源数目，其初始值是系统中所配置的该类全部可用资源的数目，其数值随该类资源的分配和回收而动态地改变。如果 Available[j] = K，则表示系统中现有j类资源K个。

（2）最大需求矩阵Max。这是一个n x m的矩阵，它定义了系统中n个进程中的每个进程对m类资源的最大需求。如果Max[i,j] = K，则表示 进程i 需要 j 类资源的最大数目为K。

(3) 分配矩阵 Allocation。这也是一个n x m的矩阵，它定义了系统中每一类资源当前已分配给每一进程的资源数。如果 Allocation[i,j] = K，则表示  进程i  当前己分得 j类资源的数目为K。

(4) 需求矩阵Need。这也是一个n×m的矩阵，用以表示每一个进程尚需的各类资源数。如果Need[i,j] = K，则表示进程i还需要 j类资源K个方能完成其任务。


上述三个矩阵间存在下述关系:

　　　　　　　　　　　　　　Need[i,j] = Max[i,j] - allocation[i, j] 

 

2.2.4  具体例子

安全序列：即 多个进程的执行顺序。只有 Available >=  Need 的序列才是安全序列。