最近很多小伙伴都在问sqlserver死锁原因及解决方法和sqlserver死锁的原因这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给你拓展I2C死锁原因及解决方法、I2C死锁原因及解决

最近很多小伙伴都在问sqlserver 死锁原因及解决方法和sqlserver死锁的原因这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给你拓展I2C 死锁原因及解决方法、I2C死锁原因及解决方法（转）、Java中多线程详解（2）产生死锁原因及解决方法、MSSQL产生死锁的根本原因及解决方法等相关知识，下面开始了哦！

• sqlserver 死锁原因及解决方法（sqlserver死锁的原因）
• I2C 死锁原因及解决方法
• I2C死锁原因及解决方法（转）
• Java中多线程详解（2）产生死锁原因及解决方法
• MSSQL产生死锁的根本原因及解决方法

sqlserver 死锁原因及解决方法（sqlserver死锁的原因）

I2C 死锁原因及解决方法

OSC 请你来轰趴啦！1028 苏州源创会，一起寻宝 AI 时代

原因

当单片机正在和 I2C 从机通信，如果主正好发生打算发第 9 个时钟，此时 SCL 为高，而从开始拉低 SDA 为低做准备（作为 ACK 信号），等待主 SCL 变低后，从再释放 SDA 为高。如果此时正好单片机复位，主 SCL 还没来得及变低，直接变成高电平，此时从还在等待 SCL 变低，所以一直拉低 SDA；而主由于复位，发现 SDA 一直为低，也在等待从释放 SDA 为高。因此主从都进入一个相互等待的死锁状态。

解决办法

1. 最好的方法是采用模拟 i2c. 但由于已经配置成硬件 i2c, 程序改为上电或复位改成发 9 个 SCL 时钟信号，使从好释放 SDA。
2. 尽量选用带复位输人的 I2C 从器件。
3. 将所有的从 I2C 设备的电源连接在一起，通过 MOS 管连接到主电源，而 MOS 管的导通关断由 I2C 主设备来实现。
4. 在 I2C 从设备设计看门狗的功能。
5. 在 I2C 主设备中增加 I2C 总线恢复程序。每次 I2C 主设备复位后，如果检测到 SDA 数据线被拉低，则控制 I2C 中的 SCL 时钟线产生 9 个时钟脉冲 (针对 8 位数据的情况)，这样 I2C 从设备就可以完成被挂起的读操作，从死锁状态中恢复过来。 这种方法有很大的局限性，因为大部分主设备的 I2C 模块由内置的硬件电路来实现，软件并不能够直接控制 SCL 信号模拟 产生需要时钟脉冲。
6. 在 I2C 总线上增加一个额外的总线恢复设备。这个设备监视 I2C 总线。当设备检测到 SDA 信号被拉低超过指定时间 时，就在 SCL 总线上产生 9 个时钟脉冲，使 I2C 从设备完成读操作，从死锁状态上恢复出来。总线恢复设备需要有具有编程 功能，一般可以用单片机或 CPLD 实现这一功能。
7. 在 I2C 上串人一个具有死锁恢复的 I2C 缓冲器，如 Linear 公司的 LTC4307:LTC4307 是一个双向的 I2C 总线缓冲器，并且具有 I2C 总线死锁恢复的功能。LTC4307 总线输人侧连接主设备，总线输出侧连接所有从设备。当 LTC4307 检测到输出侧 SDA 或 SCL 信号被拉低 30ms 时，就自动断开 I2C 总线输人侧与输出侧的连接。并且在输出侧 SCL 信号上产生 16 个时钟脉冲来释放总线。当总线成功恢复后，LTC4307 会再次连接输人输出侧，使总线能够正常工作。

I2C死锁原因及解决方法（转）

死锁总线表现为：SCL为高，SDA一直为低

现象：单片机采用硬件i2c读取E2PROM，当单片机复位时，会有概率出现再无法与E2PROM通信，此时SCL为高，SDA一直为低

原因：当单片机正在和E2PROM通信，如果主正好发生打算发第9个时钟，此时SCL为高，而从开始拉低SDA为低做准备（作为ACK信号），等待主SCL变低后，从再释放SDA为高。如果此时正好单片机复位，主SCL还没来得及变低，直接变成高电平，此时从还在等待SCL变低，所以一直拉低SDA；而主由于复位，发现SDA一直为低，也在等待从释放SDA为高。因此主从都进入一个相互等待的死锁状态。

解决方法：最好的方法是采用模拟i2c. 但由于已经配置成硬件i2c,程序改为上电或复位改成发9个SCL时钟信号,使从好释放SDA。

 最近发现单片机（硬件I2C实现）读取E2PROM时候，单片机复位可能会引起i2C死锁，表现为SCL为高，SDA一直为低，后发现是E2PROM从设备拉死i2c总线，从设备断电之后，SDA变高，上电后通信正常。后来通过拉低SCL信号线，SDA就会自动变成高电平，i2c总线恢复。后查看一篇文章，讲的不错，特摘录如下：

    在正常情况下，I2C总线协议能够保证总线正常的读写操作。但是，当I2C主设备异常复位时(看门狗动作，板上电源异常
导致复位芯片动作，手动按钮复位等等)有可能导致I2C总线死锁产生。下面详细说明一下总线死锁产生的原因。

    在I2C主设备进行读写操作的过程中.主设备在开始信号后控制SCL产生8个时钟脉冲，然后拉低SCL信号为低电平，在这个时候，从设备输出应答信号，将SDA信号拉为低电平。如果这个时候主设备异常复位，SCL就会被释放为高电平。此时，如果从设备没有复位，就会继续I2C的应答，将SDA一直拉为低电平，直到SCL变为低电平，才会结束应答信号。而对于I2C主设备来说.复位后检测SCL和SDA信号，如果发现SDA信号为低电平，则会认为I2C总线被占用，会一直等待SCL和SDA信号变为高电平。这样，I2C主设备等待从设备释放SDA信号，而同时I2C从设备又在等待主设备将SCL信号拉低以释放应答信号，两者相互等待，I2C总线进人一种死锁状态。同样，当I2C进行读操作，I2C从设备应答后输出数据，如果在这个时刻I2C主设备异常复位而此时I2C从设备输出的数据位正好为0，也会导致I2C总线进入死锁状态。

SCL为高，SDA一直为低原因

从：正常时序下：SDA信号是在SCL为低的状态下改变，即从应答SDA为低电平时，此时SCL应为为低电平(即从设备是先拉低SDA信号，等待主设备SCL由高变低，“取走”ACK信号后，从再释放SDA为高）。但如果此时时序被打乱，例如单片机i2c通信时突然复位，SCL突然变高，则从设备SDA一直为低，等待SCL变低。

主：SDA被从拉低，故主认为i2c总线占用，一直等待SDA变高

这样主从进入一个相互等待的死锁过程。

 方法

    最好用模拟I2C实现，则不会死锁

    (1)尽量选用带复位输人的I2C从器件。

    (2)将所有的从I2C设备的电源连接在一起，通过MOS管连接到主电源，而MOS管的导通关断由I2C主设备来实现。
    (3)在I2C从设备设计看门狗的功能。

    (4)在I2C主设备中增加I2C总线恢复程序。每次I2C主设备复位后，如果检测到SDA数据线被拉低，则控制I2C中的
SCL时钟线产生9个时钟脉冲(针对8位数据的情况)，这样I2C从设备就可以完成被挂起的读操作，从死锁状态中恢复过来。
这种方法有很大的局限性，因为大部分主设备的I2C模块由内置的硬件电路来实现，软件并不能够直接控制SCL信号模拟
产生需要时钟脉冲。

  (5)在I2C总线上增加一个额外的总线恢复设备。这个设备监视I2C总线。当设备检测到SDA信号被拉低超过指定时间
时，就在SCL总线上产生9个时钟脉冲，使I2C从设备完成读操作，从死锁状态上恢复出来。总线恢复设备需要有具有编程
功能，一般可以用单片机或CPLD实现这一功能。

  (6)在I2C上串人一个具有死锁恢复的I2C缓冲器，如Linear公司的LTC4307如图2所示:LTC4307是一个双向的I2C
总线缓冲器，并且具有I2C总线死锁恢复的功能。LTC4307总线输人侧连接主设备，总线输出侧连接所有从设备。当LTC4307
检测到输出侧SDA或SCL信号被拉低30ms时，就自动断开I2C总线输人侧与输出侧的连接.并且在输出侧SCL信号上产生16个时钟脉冲来释放总线。当总线成功恢复后，LTC4307会再次连接输人输出侧，使总线能够正常工作

Java中多线程详解（2）产生死锁原因及解决方法

一、什么是死锁

死锁理解起来很简单，就是一个字，堵，下面图中拥堵的十字路口就可以看做一个死锁的状态，四个方向的车都要往前走，但是十字路口只有一个，只能允许一个方向的车通过后，才能让另一个方向的车通过。

在多线程中，四个方向的车流就可以看做4个线程，而十字路口可以看做一个资源对象，四个线程都要占有它，会导致程序无法正常的运行，这就叫死锁，是不是很容易理解呢。

用比较官方的解释死锁的话，就是经典的四大条件

1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用

2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。

3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。

4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

当上述四个条件都成立的时候，便形成死锁。当然，死锁的情况下如果打破上述任何一个条件，便可让死锁消失。

二、创建死锁案例

public class DeadLock {
    public static String r1="r1";
    public static String r2="r2";
    public static void main(String[] args) {
        Runable1 runable1=new Runable1();
        Runable2 runable2=new Runable2();
        Thread thread1=new Thread(runable1);
        Thread thread2=new Thread(runable2);
        thread1.start();
        thread2.start();
    }
}
class Runable1 implements Runnable{
    @Override
    public void run() {
        try {
             (DeadLock.r1) {
                System.out.println("r1的synchronized锁住r1");
                Thread.sleep(3000);
                synchronized (DeadLock.r2) {
                    System.out.println("拿不到r2略略略");
                    Thread.sleep(60 * 1000);
                }
                System.out.println("被锁住了，无法打印");
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
class Runable2 implements Runnable{
    @Override
    public void run() {
        try {
            synchronized (DeadLock.r2){
                System.out.println("synchronized锁住r2");
                Thread.sleep(3000);
                synchronized (DeadLock.r1){
                    System.out.println("拿不到r1略略略");
                    Thread.sleep(60 * 1000);
                }
                System.out.println("被锁住了，无法打印");
            }
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}
//运行结果
r1的synchronized锁住r1
synchronized锁住r2
复制代码

在上面这个案例中，先创建了两个资源对象r1和r2,然后创建了两个线程类Runable1和Runable2，用synchronized方法去给资源添加锁，使得两个线程在执行完run方法之前都不会释放资源对象r1和r2，（synchronized方法的作用就是一个同步锁，代码中放入synchronized括号中的资源在线程结束前都不会释放，也就不能被其他线程使用）之后用sleep方法让线程阻塞（sleep（3000）的作用是是给线程能锁住机会，sleep（60*1000）的作用是让线程阻塞），这样就造成了死锁的现象，导致后面的语句无法打印出来。

三、如何解决死锁问题

1.在写多线程操作时，最好不要一次锁定多个对象，这样就不会导致死锁了。修改后的代码如下。

public class DeadLock {
    public static String r1="r1";
    public static String r2="r2";
    public static void main(String[] args) {
        Runable1 runable1=new Runable1();
        Runable2 runable2=new Runable2();
        Thread thread1=new Thread(runable1);
        Thread thread2=new Thread(runable2);
        thread1.start();
        thread2.start();
    }
}
class Runable1 implements Runnable{
    @Override
    public void run() {
        try {
            synchronized (DeadLock.r1) {
                System.out.println("r1的synchronized锁住r1");
                Thread.sleep(3000);
                    System.out.println("拿到r2");
                    Thread.sleep(3000);
                System.out.println("解锁了，可以打印");
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
class Runable2 implements Runnable{
    @Override
    public void run() {
        try {
            synchronized (DeadLock.r2){
                System.out.println("synchronized锁住r2");
                Thread.sleep(3000); 
                   System.out.println("拿到r1");
                    Thread.sleep(3000);
                System.out.println("解锁了，可以打印");
            }
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}
//运行结果
r1的synchronized锁住r1
synchronized锁住r2
拿到r2
拿到r1
解锁了，可以打印
解锁了，可以打印
复制代码

2.如果业务场景需要一次锁定多个资源对象，可以根据资源的某个属性或者hashCode值来做比较，定义锁的先后顺序，下面是一个通过hashCode来定义锁先后顺序的例子。

public class DeadLock {
    public static String r1="r1";
    public static String r2="r2";
    public static void main(String[] args) {
        Runable1 runable1=new Runable1();
        Runable2 runable2=new Runable2();
        Thread thread1=new Thread(runable1);
        Thread thread2=new Thread(runable2);
        thread1.start();
        thread2.start();
    }
}
class Runable1 implements Runnable{
    @Override
    public void run() {
        try {
            if (DeadLock.r1.hashCode()>DeadLock.r2.hashCode()) {
                synchronized (DeadLock.r1) {
                    System.out.println("Runable1的synchronized锁住r1");
                    Thread.sleep(3000);
                    synchronized (DeadLock.r2) {
                        System.out.println("Runable1的synchronized锁住r2");
                        Thread.sleep(3000);
                    }
                    System.out.println("解锁了，可以打印");
                }
            }else{
                synchronized (DeadLock.r2) {
                    System.out.println("Runable1的synchronized锁住r1");
                    Thread.sleep(3000);
                    synchronized (DeadLock.r1) {
                        System.out.println("Runable1的synchronized锁住r2");
                        Thread.sleep(3000);
                    }
                    System.out.println("解锁了，可以打印");
                }
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
class Runable2 implements Runnable{
    @Override
    public void run() {
        try {
            if (DeadLock.r1.hashCode()<DeadLock.r2.hashCode()) {
                synchronized (DeadLock.r2) {
                    System.out.println("Runable2的synchronized锁住r2");
                    Thread.sleep(3000);
                    synchronized (DeadLock.r1) {
                        System.out.println("Runable2的synchronized锁住r1");
                        Thread.sleep(3000); 
                   }
                    System.out.println("解锁了，可以打印");
                }
            }else{
                synchronized (DeadLock.r1) {
                    System.out.println("Runable2的synchronized锁住r1");
                    Thread.sleep(3000);
                    synchronized (DeadLock.r2) {
                        System.out.println("Runable2的synchronized锁住r2");
                        Thread.sleep(3000);
                    }
                    System.out.println("解锁了，可以打印");
                }
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
//运行结果
Runable1的synchronized锁住r1
Runable1的synchronized锁住r2
解锁了，可以打印
Runable2的synchronized锁住r1
Runable2的synchronized锁住r2
解锁了，可以打印

参考：《2020最新Java基础精讲视频教程和学习路线！》
链接：https://juejin.cn/post/694043...

MSSQL产生死锁的根本原因及解决方法

一、 什么是死锁

死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程.

二、 死锁产生的四个必要条件

•互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放

•请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放

•不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放

•环路等待条件：指在发生死锁时，必然存在一个进程――资源的环形链，即进程集合{P0，P1，P2，・・・，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源

这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

三、 如何处理死锁

1) 锁模式

1.共享锁（S）

由读操作创建的锁，防止在读取数据的过程中，其它事务对数据进行更新；其它事务可以并发读取数据。共享锁可以加在表、页、索引键或者数据行上。在sql SERVER默认隔离级别下数据读取完毕后就会释放共享锁，但可以通过锁提示或设置更高的事务隔离级别改变共享锁的释放时间。

2.独占锁(X)

对资源独占的锁，一个进程独占地锁定了请求的数据源，那么别的进程无法在此数据源上获得任何类型的锁。独占锁一致持有到事务结束。

3.更新锁(U)

更新锁实际上并不是一种独立的锁，而是共享锁与独占锁的混合。当sql SERVER执行数据修改操作却首先需要搜索表以找到需要修改的资源时，会获得更新锁。

更新锁与共享锁兼容，但只有一个进程可以获取当前数据源上的更新锁，

其它进程无法获取该资源的更新锁或独占锁，更新锁的作用就好像一个序列化阀门（serialization gate），将后续申请独占锁的请求压入队列中。持有更新锁的进程能够将其转换成该资源上的独占锁。更新锁不足以用于更新数据―实际的数据修改仍需要用到独占锁。对于独占锁的序列化访问可以避免转换死锁的发生，更新锁会保留到事务结束或者当它们转换成独占锁时为止。

4. 意向锁(IX,IU,IS)

意向锁并不是独立的锁定模式，而是一种指出哪些资源已经被锁定的机制。

如果一个表页上存在独占锁，那么另一个进程就无法获得该表上的共享表锁，这种层次关系是用意向锁来实现的。进程要获得独占页锁、更新页锁或意向独占页锁，首先必须获得该表上的意向独占锁。同理，进程要获得共享行锁，必须首先获得该表的意向共享锁，以防止别的进程获得独占表锁。

5. 特殊锁模式(Sch_s,Sch_m,BU)

sql SERVER提供3种额外的锁模式：架构稳定锁、架构修改锁、大容量更新锁。

6.转换锁(SIX,SIU,UIX)

转换锁不会由sql SERVER 直接请求，而是从一种模式转换到另一种模式所造成的。sql SERVER 2008支持3种类型的转换锁：SIX、SIU、UIX.其中最常见的是SIX锁，如果事务持有一个资源上的共享锁（S），然后又需要一个IX锁，此时就会出现SIX。

7.键范围锁

键范围锁是在可序列化隔离级别中锁定一定范围内数据的锁。保证在查询数据的键范围内不允许插入数据。

2) 锁粒度

sql SERVER 可以在表、页、行等级别锁定用户的数据资源即非系统资源（系统资源是用闩锁来保护的）。此外sql SERVER 还可以锁定索引键和索引键范围。

通过sys.dm_tran_locks视图可以查看谁被锁定了（如行，键，页）、锁的模式以及特定资源的标志符。基于sys.dm_tran_locks视图创建如下视图用于查看锁定的资源以及锁模式（通过这个视图可以查看事务锁定的表、页、行以及加在数据资源上的锁类型）。

CREATE VIEW dblocks AS 
SELECT request_session_id AS spid,DB_NAME(resource_database_id) AS dbname,CASE WHEN resource_type='object' 
THEN OBJECT_NAME(resource_associated_entity_id) 
WHEN resource_associated_entity_id=0 THEN 'n/a' 
ELSE OBJECT_NAME(p.object_id) END AS entity_name,index_id,resource_type AS RESOURCE,resource_description AS DESCRIPTION,request_mode AS mode,request_status AS STATUS 
FROM sys.dm_tran_locks t LEFT JOIN sys.partitions p ON p.partition_id=t.resource_associated_entity_id 
WHERE resource_database_id=DB_ID()

3) 如何跟踪死锁

通过选择sql server profiler 事件中的如下选项就可以跟踪到死锁产生的相关语句。

4) 死锁案例分析

在该案例中process65db88,process1d0045948为语句1的进程，process629dc8 为语句2的进程； 语句2获取了1689766页上的更新锁，在等待1686247页上的更新锁；而语句1则获取了1686247页上的更新锁在等待1689766页上的更新锁，两个语句等待的资源形成了一个环路，造成死锁。

5) 如何解决死锁

针对如上死锁案例，分析其对应语句执行计划如下：

通过执行计划可以看出，在查找需要更新的数据时使用的是索引扫描，比较耗费性能，这样就造成锁定资源时间过长，增加了语句并发执行时产生死锁的概率。

处理方式：

1． 在表上建立一个聚集索引。

2． 对语句更新的相关字段建立包含索引。

优化后该语句执行计划如下：

优化后的执行计划使用了索引查找，将大幅提升该查询语句的性能，降低了锁定资源的时间，同时也减少了锁定资源的范围，这样就降低了锁资源循环等待事件发生的概率，对于预防死锁的发生会有一定的作用。

死锁是无法完全避免的，但如果应用程序适当处理死锁，对涉及的任何用户及系统其余部分的影响可降至最低（适当处理是指发生错误1205时，应用程序重新提交批处理，第二次尝试大多能成功。一个进程被杀死，它的事务被取消，它的锁被释放，死锁中涉及到的另一个进程就可以完成它的工作并释放锁，所以就不具备产生另一个死锁的条件了。）

四、 如何预防死锁

阻止死锁的途径就是避免满足死锁条件的情况发生，为此我们在开发的过程中需要遵循如下原则：

1.尽量避免并发的执行涉及到修改数据的语句。

2.要求每一个事务一次就将所有要使用到的数据全部加锁，否则就不允许执行。

3.预先规定一个加锁顺序，所有的事务都必须按照这个顺序对数据执行封锁。如不同的过程在事务内部对对象的更新执行顺序应尽量保证一致。

4.每个事务的执行时间不可太长，对程序段的事务可考虑将其分割为几个事务。在事务中不要求输入，应该在事务之前得到输入，然后快速执行事务。

5.使用尽可能低的隔离级别。

6.数据存储空间离散法。该方法是指采用各种手段，将逻辑上在一个表中的数据分散的若干离散的空间上去，以便改善对表的访问性能。主要通过将大表按行或者列分解为若干小表，或者按照不同的用户群两种方法实现。

7.编写应用程序，让进程持有锁的时间尽可能短，这样其它进程就不必花太长的时间等待锁被释放。

今天关于sqlserver 死锁原因及解决方法和sqlserver死锁的原因的讲解已经结束，谢谢您的阅读，如果想了解更多关于I2C 死锁原因及解决方法、I2C死锁原因及解决方法（转）、Java中多线程详解（2）产生死锁原因及解决方法、MSSQL产生死锁的根本原因及解决方法的相关知识，请在本站搜索。