数据库死锁

事务处理和并发控制 一、事务管理简介 1、事务含义 2、事务的属性ACID 四大属性：原子性、一致性、隔离性、持久性。 3、事务块管理的常用语句 BEGIN 和COMMIT同时用，是用来标识事务的开始和结束。 4、案例 ①、创建表 ②、插入数据并查询 二、事务并发控制 数据库中的数据并发操作经常发生，会出现： 1、脏读 2、幻读 3、不可重复性读取 三、锁机制 需要使用锁机制来保证事务的并发。使用锁可以解决用户存取数据的这个问题，从而保证数据库的完整性和一致性。 （一）、锁的类型 1、SpinLock (自旋锁) 2、LWLock (轻量级锁) 3、RegularLock 是一般数据库事务管理中所指的锁。只要特点是等待队列、死锁检测和能自动释放锁。 （二）、死锁 1、死锁出现的原因 行程死锁的必要条件： 2、可能会造成死锁的原因 ①、锁：等待获取资源（如对象、页、行、元数据和应用程序）的锁可能导致死锁。 ②、工作线程：排队等待可用工作线程的任务可能导致死锁。如果排队等待的任务拥有阻塞所有工作线程的资源，则将导致死锁。 ③、内存：当并发请求等待获得内存，而当前的可用内存无法满足其需求时、可能发生死锁。 ④、并行查询的相关资源。通常与交换端口关联的处理协调器、发生器或使用者线程至少包含一个不属于并行查询进程时，可能会互相阻塞，从而导致死锁。 3、减少死锁的策略

1、问题描述： 1.1编译存过时未响应，强行关掉编辑器后，存过死锁了 1.2表死锁，无法进行保存、修改操作 2、问题解决： -- 查询死锁的信息 select object_name,machine,s.sid,s.serial# from v$locked_object l,dba_objects o ,v$session s where l.object_id　=　o.object_id and l.session_id=s.sid; -- 删除死锁 alter system kill session 'sid,serial#'; --例子： alter system kill session '543,13103'; 来源：博客园 作者： shelly双鱼座 链接：https://www.cnblogs.com/shelly0307/p/11818461.html

锁的定义：死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。竞争的资源可以是：锁、网络连接、磁盘共享变量等一切可以称作是 【资源】的东西。 我们使用锁来保证线程安全，但是使用不当与滥用可能就会引起死锁。并发程序一旦死锁，一般没有特别好的办法，很多时候只能重启。所以我们一定要比避免死锁。 举个不恰当的例子：现在岳不群通过阴谋手段获取到了葵花宝典的上册，然后就闭关修炼自宫了，此刻他想继续争夺下册一块练，不然自宫就白忙活了。这个时候下册被林平之拿到了，他也要修炼葵花宝典，所以藏着下册去找上册来自宫。现在问题来了，岳不群找不到下册。林平之拿不到上册，两个人就只能干瞪眼谁也不肯交出自己的，同事还要获取对方的。 如果此时有一个线程 A ，按照先获持有锁 a 再获取锁 b的顺序获得锁，同时另外一个线程 B，按照先获取锁 b 再获取锁 a 的顺序获取锁。如下图所示： 接着我们用代码模拟上线的执行过程，默认使用 SpringBoot 环境 @Component public class DeadLock { private static Object lockA = new Object (); private static Object lockB = new Object (); public void

并发性：死锁和饥饿 死锁 基本概念 死锁：一组相互竞争系统资源或进行通信的进程间“永久”阻塞的情况。当一组进程中的每个进程都在等待某个事件，而只有在这组进程中的其他被阻塞的进程才可以触发该事件，这组进程就发生死锁。因为没有事件能够被触发，因此死锁是永久性的。 活锁：指的是任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试―失败―尝试―失败的过程。处于活锁的实体是在不断的改变状态，活锁有可能自行解开。（类似于不断谦让的过程） 可重用资源：一次只能供一个进程安全地使用，并且不会由于使用而耗尽的资源。如处理器/ io通道、内存外存、设备以及文件、数据库和信号量等。 可消耗资源：可以被创建(生产)和销毁(消耗)的资源。这种资源的数目没有显示，一个无阻塞的生产进程可以创建任意数目的这类资源。当一个消费进程得到一个资源的时候，该资源就不再存在了。比如有中断、信号、消息和I/O缓冲区中的信息。 资源分配图：刻画进程的资源分配的有向图。 参考 死锁的条件 死锁产生的主要原因包括系统资源的竞争以及进程推进顺序非法。 死锁产生有三个必要条件： 1.互斥：一次只有一个进程可以使用一个资源。其他进程不能访问已分配给其他进程的资源 占有且等待：当一个进程等待其他进程的时候，继续占有已分配的资源 不可抢占：不可强行抢占进程已占有的资源 满足前三个条件，可能发生的一系列事件会导致不可解的循环等待

并发测试： 并发测试（Concurrency Testing）方法通过模拟用户的并发访问，测试多用户并发访问同一应用、同一个模块或者数据记录时是否 存在死锁或者其他性能问题。 特点： （1）这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。 该方法是通过并发的手段发现系统中存在问题的最常用的方法。 （2）该性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。 内存问题： 1.是否有内存泄漏 2.是否有太多的临时对象 3.是否有太多的超过设计生命周期的对象 数据库问题： 1.是否有数据库死锁（Dead Lock） 2.是否经常出现长事务(Long Transaction) 线程/进程问题： 1.是否出现线程/进程同步失败 其他问题： 1.是否出现资源争用导致的死锁 2.是否没有正确处理异常（如超时）导致系统死锁 （3）该测试方法可以在开发的各个阶段使用，需要相关的测试工具配合和支持 2. 负载测试： 负载测试(Load Testing)方法通过在被测系统上不断增加压力，直到性能指标，例如"响应时间"超过预定指标或者某种资源使用 已经达到饱和状态。 这种测试方法可以找到系统的处理极限，为系统调优提供数据。在某些情况下，这种方法有时也被称为可量性测试(Scalability Testing). 特点： （1

锁 一、概念 　　锁是计算机协调多个进程或线程访问某一个资源的机制。在数据库中，除传统的计算资源（CPU、RAM、IO）的争用意外，数据也是一种许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问的一个重要因素。从这个角度来说，锁对数据库尤其重要，也更加复杂。本文就以MyISAM和InnoDB两个引擎来说明锁的问题； 二、MySQL锁概述 　　相对其他数据库而言，MySQL的锁机制比较简单，其中最为显著的特点是不同的引擎具有不同的锁。比如MyISAM和InnoDB分别采用表锁、行锁，但是InnoDB也支持表锁，默认情况下采用行锁； 三、MySQL表锁和行锁对比 锁的名称 开销 加锁速度 死锁 粒度 并发性能 表锁 С 快 不会出现 大 最低 行锁 大 慢 出现 С 最高 从锁的角度来说表锁适合查询为主，只有少量按索引条件更新数据的应用；行锁适合于大量按索引条件来并发更新少量的数据，同时又有并发查询的应用； MyISAM表锁 　　可以通过table_locks_waited和table_locks_immediate来分析系统表锁的争夺； 如果table_locks_waited的值比较高的话，则说明存在较高的表锁争夺。 二、表锁的锁模式 　　表级锁有两种方式：读锁和写锁，锁模式的兼容性如下: 由上表可见

Reference： https://time.geekbang.org/column/article/117247 死锁产生 行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。 record lock是专门对索引项加锁； gap lock是对索引项之间的间隙加锁； next-key lock则是前面两种的组合，对索引项及其之间的间隙加锁。 只在可重复读或以上隔离级别下的特定操作才会取得gap lock或next-key lock，在Select、Update和Delete时，除了基于唯一索引的查询之外，其它索引查询时都会获取gap lock或next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用gap lock或next-key lock。 在MySQL中，gap lock默认是开启的，即innodb_locks_unsafe_for_binlog参数值是disable的，且MySQL中默认的是RR事务隔离级别。 当执行以下查询SQL时，由于order_no列为非唯一索引，此时又是RR事务隔离级别，所以SELECT的加锁类型为gap lock，这里的gap范围是(4,+∞）。 1 SELECT id FROM demo.order_record where order_no = 4 for

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 1.2 wait-for graph原理 1.2.1 锁与索引的关系 id: bigint token: varchar(30) message: varchar(4096) 1）delete from msg where id=2； 2）delete from msg where token=’ cvs’; 3）delete from msg where message=订单号是多少’； 1.2.2 锁与隔离级别的关系 1）未提交读（Read uncommitted）； 2）已提交读（Read committed（RC））； 3）可重复读（Repeatable read（RR））； 4）可串行化（Serializable）。 我们较常使用的是RC和RR。 RC级别下尽管加了行锁，但还是避免不了幻读。 RR隔离级别 可以避免幻读发生，怎么实现？当然需要借助于锁了！ gap锁（间隙锁） 。 3 死锁成因 3.1不同表相同记录行锁冲突 3.2相同表记录行锁冲突 3.3不同索引锁冲突 3.4 gap锁冲突 4 如何尽可能避免死锁 1）以固定的顺序访问表和行。比如对第2节两个job批量更新的情形

锁粒度 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较 表级锁 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现

在什么情况下使用线程池？ 1.单个任务处理的时间比较短 2.将需处理的任务的数量大 使用线程池的好处: 1.减少在创建和销毁线程上所花的时间以及系统资源的开销 2.如不使用线程池，有可能造成系统创建大量线程而导致消耗完系统内存以及”过度切换”。 线程池工作原理： 为什么要用线程池？ 诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP 或 POP）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。 构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上，对于原型开发这种方法工作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程（thread-per-request）方法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。 除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM