官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。
十余年的灵台网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销的优势是能够根据用户设备显示端的尺寸不同，自动调整灵台建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联从事“灵台网站设计”,“灵台网站推广”以来，每个客户项目都认真落实执行。
这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。
看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？居然还要操作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了。
MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。那么为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（ 可串行化调度 ）。具体的并发控制这里不再展开。咱们继续深入讨论两阶段锁协议。
官方定义：
对应到 MySQL 上分为两个阶段：
就是说呢，只有遵循两段锁协议，才能实现 可串行化调度 。
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。
MySQL有两种死锁处理方式：
由于性能原因，一般都是使用死锁检测来进行处理死锁。
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
MySQL如何处理死锁
mysql一般不会死锁，除非程序有问题。性能优先事务不优先的数据库（设置）不要追求可靠性万无一失。
网站性能问题主要是数据库量大了以后，查询扫描硬盘而产生的。其它性能不要太在意。编写代码的时候不要坚持性能原则，而是坚持可用性原则。初学者编写代码通常容易面向性能，但是一个项目的一个页面几百、几千行代码是很常见的。要面向可用性、可维护性、可读性。这是项目原则。你看看java语言。对于网站，除了查询扫描硬盘而产生的时间延迟，其它是不管的，只要不算有问题就可以。
连接方式是否为永久连接，在访问量未达到高并发之前，还是非永久链接更好。非永久连接的资源消耗是不大于永久连接的，因为mysql是把连接权限缓存的，不会多次扫描硬盘，性能是可执行级别的而不是查找数据级别的。在访问量达到高并发之后，性能问题的原因是多方面的，多环节的，是否为永久连接不是主要原因。
一、show ENGINE INNODB status
查看死锁位置，分析。
二、
首先解决死锁可以从死锁发生的条件入手，最容易解决的就是更改获取资源的顺序；
其次是避免长事务，让事务执行的时间尽可能少，让事务的覆盖范围尽可能小，长事务会导致并发度降低，且会有更多的SQL查 询延迟；
给整个方法加事务是否是必须的？可以不加事务的尽量不加。
一、活锁
如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，...，T2有可能永远等待，这就是活锁的情形，如图8.4(a)所示。
避免活锁的简单方法是采用先来先服务的策略。
二、死锁
如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。
1. 死锁的预防
在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：
① 一次封锁法
一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。
② 顺序封锁法
顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。
顺序封锁法可以有效地防止死锁，但也同样存在问题。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。
可见，在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。
2. 死锁的诊断与解除
① 超时法
如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。
② 等待图法
事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2,则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。
DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。当然，对撤消的事务所执行的数据修改操作必须加以恢复。
(看标签只有java和mysql的，就挑出来说了，其他方面的我也没啥可以说的...)
运行时发现死锁：
java进程用jstack打出堆栈看看有没有就知道有没有死锁
mysql innodb的话，show engine innodb status 看看锁持有情况也能看的出来有没有死锁
怎么处理：首先肯定优先恢复服务。该回滚版本的回滚版本，该杀的杀，该重启的重启。
java进程：看jstack的堆栈找到阻塞的位置，然后对着代码分析
mysql：show engine innodb status已经可以看的到sql以及等待什么锁 etc.，对着分析就好，看不到sql的话可以用thread id去查mysql 的bin log查到具体执行的sql。
避免死锁：
我是没什么好的办法，只能说所有涉及到多线程操作的地方都要提高警惕，涉及到资源竞争、加锁的地方都要提高警惕，分析清楚该逻辑会不会产生死锁。
条件允许的情况下可以做并发测试。