数据库死锁

一、jstack命令 jstack Dump 日志文件中的线程状态 dump 文件里，值得关注的线程状态有： 死锁， Deadlock（重点关注） 执行中， Runnable 等待资源， Waiting on condition（重点关注） 等待获取监视器， Waiting on monitor entry（重点关注） 暂停， Suspended 对象等待中， Object.wait() 或 TIMED_WAITING 阻塞， Blocked（重点关注） 停止， Parked 下面我们先从第一个例子开始分析，然后再列出不同线程状态的含义以及注意事项，最后再补充两个实例。 综合示范一： Waiting to lock 和 Blocked 实例如下： "RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [ 0x00007fd4f8684000 ] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock

写在前面 这篇文章是在网络上看到其他作者的优秀博文，自己消化理解之后所做的记录。文章基于 MySQL 中的 InnoDB 存储引擎。 原博文地址： 点我 锁 锁知识概览 我们先看一张锁的概览图，方便后续的讲述： 我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库 隐式 帮我们加了；只在某些特定的场景下，才需要程序员手动加锁。 在执行「查询语句」 SELECT 前，会自动给涉及的所有表加「表级锁」中的 读锁 ；在执行「更新操作」 UPDATE、DELETE、INSERT 前，会自动给涉及的表加「表级锁」中的 写锁 对于 InnoDB ,且 使用了索引 的「更新操作」 UPDATE、DELETE、INSERT 语句；这时 InnoDB 会将「表锁」转换成「行锁」，也就是会自动给涉及数据集加「行级锁」中的 排他锁（X) 注意 ：InnoDB 只有通过「索引」检索数据才使用「行级锁」，否则，InnoDB将使用表锁；也就是说，InnoDB 的 行锁基于索引 。 一种特殊情况 如果我们对表中的某列加的是「普通索引」，那也就意味着： 索引列属性可能重复 。 对于普通索引，当 重复率高 时，MySQL 不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而 形成表锁 。 锁的分类 从上图中，以锁的粒度出发，我们可以看到锁分为「表级锁」和「行级锁」 『表锁』：开销小，加锁快

1.问题背景 刚来新公司不久，对业务还不太熟悉，所以领导先安排我维护原有系统。大概介绍下项目背景，项目分为核心业务部分在项目A中，与第三方交互的业务在项目B中，前端发起请求调用A项目接口，并在A项目中调用B项目接口，并在B项目中调用第三方获取数据（原有系统这样设计的）。 获取到第三方数据后判断数据库中是否有该记录（有唯一键），如有则执行更新操作，没有则新增。并且如果第三方认为该数据已失效，需要从数据库中删除(逻辑删除)，并返回第三方删除成功回调，后续便不会再查到已失效的数据。 对应流程图如下 在代码处理中对整个过程加事务@Transactional注解，即在对数据进行删除(逻辑删除，实际执行update语句)时会根据唯一索引对该行加锁。在生成环境B项目频繁出现Lock wait timeout exceeded; try restarting transaction 异常，经排查定位到该功能代码，排查代码发现该功能有如下代码 有经验的同学应该已经看出问题所在，这里将全局异常捕获，记录错误日志，但问题就出在catch这里，由于异常被catch吞噬，@Transactional无法拿到异常，所以不会执行rollback回滚，导致一直占用数据库行锁。(这里的异常是调用第三方接口失败，由于调用太频繁，第三方接口崩溃，这里后续也做了并发控制)

数据库基本知识点梳理系列 - 锁 数据库的锁是用于保证数据库事务在并发的情况下依旧能够保证数据的一致性的. 所以深入理解锁的原理, 能够帮助我们更好地理解事务隔离级别的原理, 以及在实际的业务场景中, 有把握的使用隔离级别保障系统的效率和稳定. 锁的分级 级别 加锁速度以及开销 是否会出现死锁的情况 粒度 并发事务的性能影响 表级锁 快, 开销小 不会出现死锁 锁定粒度很大, 因此发生加锁的冲突概率最高 并发度最低 行级锁 开销大, 加锁慢 会出现死锁 锁定粒度最小, 发生加锁冲突概率最低 并发度最高 页面锁 开销和加速速度介于上面两者间 会出现死锁 粒度介于上面两者之间 并发度介于两者之间 行级锁 锁名称 代号 描述 共享锁 （S） 读锁 。可以并发读取数据，但不能修改数据。也就是说当数据资源上存在共享锁的时候，所有的事务都不能对这个资源进行修改，直到数据被所有资源读取完成，共享锁释放。 排它锁 （X） 独占锁、 写锁 。就是如果你对数据资源进行增删改(DML)操作时，不允许其它任何事务操作这块资源，直到排它锁被释放，防止同时对同一资源进行多重操作。当资源上已经有共享锁或者排他锁, 则无法对这个资源添加额外的排他锁. 即排他锁与共享锁不兼容. 排他锁与自己也不兼容. 更新锁 （U） 当事务发现资源上既没有更新锁也没有排他锁时, 可以对资源添加更新锁, 也就是说,

#1 问题描述# 未签收的订单十五天之后自动签收：总共2个步骤： step1 在乐购系统中批量更新未签收订单的状态，step2: 通过RPC修改订单系统的订单状态， step1和step2放到一个事务中。然后发现step2 订单DB状态修改成功，但是step1 乐购db的订单状态并未修改。 #2 排查过程# 怀疑是程序的问题，检查乐购系统的执行日志，发现所有日志执行成功，db的插入和更新操作日志以及事务日志，都显示执行正确；【正常】 怀疑是DB执行的问题，检查DB的binglog日志，发现没有事务执行的任何记录，那数据到底是提交到哪里去了呢？ 乐购系统的日志明明是显示执行成功的啊。于是怀疑当时db执行可能有错误再检查db的errorlog发现也没有任何db执行错误信息；【正常】 怀疑是db的配置问题，因为我们当时在dev和qa环境下都测试成功，就是boss环境发生这样的奇怪问题。于是检查dev，qa和boss环境的所有配置，包括： bulk_insert_buffer_size 批量插入buffer大小，innodb_flush_log_at_trx_commit 事务提交的日志级别，lock timewait锁等待时间 ，注意这个参数很重要。 默认是5分钟吧，我们设置的是365天！！ 【不正常】 发现这三个环境没有db配置没有任何差别，唯一不同的是线上db做了主从配置

#死锁分析与解决 ##事务并发执行 ##事务持锁 MySQL数据库是以行加锁的方式，避免不同事务，对同一行数据库进行同时修改的。首先来看事务一，对张三这条记录的Account字段进行修改，需要持有张三这条数据库的行锁。然后事务二也同时并发执行，事务二首先修改李四这条数据库记录的Corp字段，持有李四这条数据库的行锁。 此时两个事务各持有一个行锁，但是接下来事务一要持有事务二的行锁，事务二要持有事务一的行锁。这样就形成了事务一与事务二相互等待，导致两个事务都无法继续执行下去。 ##死锁 死锁 ：指 两个 或者 两个以上 的事务，在执行过程中，因 争夺锁资源 而造成的一种 互相等待 的现象。 死锁必须是两个或者两个以上的事务，单个事务不可能发生死锁。死锁是因为争夺锁资源，导致相互持有锁资源，导致相互等待。需要外部干涉的现象。 ##死锁产生的必要条件 互斥 并发执行的事务为了进行必要的隔离保证执行正确，在事务结束前，需要对修改的数据库记录持锁，保证多个事务对相同数据库记录串行修改 对于大型并发系统无法避免 请求与保持 一个事务申请多个资源，已经持有一个资源锁，等待另外一个资源锁 死锁仅发生在请求两个或者两个以上的锁对象 由于应用实际需要，难以消除 不剥夺 已经获得锁资源的事务，在未执行前，不能被强制剥夺，只能使用完时，由事务自己释放。 一般用于已经出现死锁时

一、锁 　　1、数据库和操作系统一样，是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并 发控制的一个非常重要的技术。在实际应用中经常会遇到的与锁相关的异常情况，当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就会出现死锁，严重影响应用的正常执行。 　　2、在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两 种基本的锁类型来对数据库的事务进行并发控制。 　　3、死锁 　　　　（1）死锁的第一种情况 一个用户A 访问表A(锁住了表A),然后又访问表B；另一个用户B 访问表B(锁住了表B)，然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 　　　　（2）死锁的第二种情况 用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A 有共享锁存在所以必须等A释放掉共享锁

> 文章首发于： clawhub.club 1、概念 死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种相互等待的现象。 具体的介绍可以参考我以前写的一篇文章： 【并发编程挑战】死锁 2、死锁检测 以下文字全部摘抄整理自《MySQL技术内幕 InnoDB存储引擎 第二版》，在InnoDB存储引擎中，采用wait-for graph(等待图)的方式来进行死锁检测。 wait-for graph要求数据库保存一下两种信息： 锁的信息链表 事务等待链表 通过上述链表可以构造出一张图，而在这个图中若存在回路，就代表存在死锁，因此资源间相互发生等待。在wait-for graph中，事务为图中的节点。在图中，事务T1指向T2定义为： 事务T1等待事务T2所占用的资源 事务T1发生在事务T2后面 事务T2所占用的资源不会被强制剥夺 下面通过一个例子分析，当前事务与锁的状态如下图： 由图可知： 事务等待列表中有4个事务，在wait-for graph中对应4个节点。 事务t2对row1(行)占用x锁（独占锁），事务t1对row2(行)占用s锁（共享锁） 事务t1等待事务t2所占用的row1资源，因此在wait-for graph中有条边从节点t1指向t2。 事务t2等待事务t1、t4所占用的row2资源，t4对于row2占用s锁。故存在t2指向t1、t4的边。 同样

Java 基础 1. JDK 和 JRE 有什么区别？ JDK：Java Development Kit 的简称，java 开发工具包，提供了 java 的开发环境和运行环境。 JRE：Java Runtime Environment 的简称，java 运行环境，为 java 的运行提供了所需环境。 具体来说 JDK 其实包含了 JRE，同时还包含了编译 java 源码的编译器 javac，还包含了很多 java 程序调试和分析的工具。简单来说：如果你需要运行 java 程序，只需安装 JRE 就可以了，如果你需要编写 java 程序，需要安装 JDK。 2. == 和 equals 的区别是什么？ == 解读 对于基本类型和引用类型 == 的作用效果是不同的，如下所示： 基本类型：比较的是值是否相同； 引用类型：比较的是引用是否相同； 代码示例： String x = "string"; String y = "string"; String z = new String("string"); System.out.println(x==y); // true System.out.println(x==z); // false System.out.println(x.equals(y)); // true System.out.println(x.equals(z)); //

在很多应用中，需要一个进程排他性地访问若干种资源而不是一种，容易造成死锁。 死锁也有可能发生在机器之间。 加锁过程也会产生死锁。 所以，软硬件都有可能死锁。 6.1 资源 需要排他性使用的对象称为资源，可以是硬件设备或是一组信息，简单来说，资源就是随着时间推移，必须能够获得、使用以及释放地任何东西。 6.1.1 可抢占资源和不可抢占资源 可抢占资源：可以从拥有它的进程中抢占而不会产生任何副作用，如打印机和内存资源 不可抢占资源：在不引起相关地计算失败地情况下，无法把它从占有它的进程处抢占过来（如刻盘），和死锁有关 资源是否可抢占取决于上下文环境 使用一个资源要做的事： （1）请求资源 （2）使用资源 （3）释放资源 6.1.2 资源获取 对于数据库系统中记录这类资源，由用户进程来管理使用，使用信号量（初始化为1）或者互斥信号量。down获取资源，up释放资源 编码上地风格细微差别就可能造成死锁 6.2 死锁简介 死锁地规范定义：如果一个进程集合中地每个进程都在等待只能由该进程集合中地其他进程才能引发的时间，那么，该进程集合就是死锁 最常见的死锁：资源死锁 6.2.1 资源死锁的条件 （1）互斥条件 （2）占有和等待条件 （3）不可抢占条件 （4）环路等待条件 通过破坏上述条件就可以预防死锁 6.2.2 死锁建模 方形代表资源，圆形代表进程 串行运行（不会有死锁，但是效率低