1. 最简单的死锁
最常见的死锁 是因为一个事务执行时间过长，而导致另外一个事务 无法 访问 被被该事务锁定的资源，最终 超时 而导致的死锁异常. 这种情况无非有两种解决方案，一是性能调优。 二是当该事务遇到等待超时导致的死锁异常后，继续让该事务 re-try.
2. 互相等待 -- 死锁
这种 死锁的异常情况特殊，两个极短的事务 在 高并发的环境下也可能发生 相互等待 -- 死鎖 的情況.
a) 怎样导致的?
总的来说，是因为两个事务 对共有资源的CUD 执行顺序 不同导致的. 如下,
事务1: A -- > B
事务2: B -- > A
在高并发情况下，如果 相同时间内，事务1 处理完 对资源A的CUD 同时 事务2 处理完 对资源B 的CUD。 这个时候 事务1 要对 B 资源 CRUD 同时 事务2也要对 A资源 CRUD， 而此时， 事务1 锁住了A资源，事务2锁住了B资源，所以 事务1需要等待事务2释放B资源 才能继续对B资源操作，相反事务2需要等待事务1释放A资源 才能继续对A资源操作。 这样 两个事务互相等待 锁释放 而导致死锁
b) 如何解決?
唯一的办法就是 让这两个事务 对共有资源的CUD 执行顺序 一样。
事务1: A -- > B
事务2: A -- > B
有趣的问题 如果事务2 是 A --> B --> A 而事务1保持不变， 当事务2 执行完B资源操作 再次对A资源操作的时候 会不会出现死锁呢， 看起来如果事务1同时也执行到对B资源操作的时候 - 好像会， 但答案是不会.
原因很简单，因为 A资源已经被 事务2 锁定， 事务1 不会有机会启动，只有等待 事务2 释放 A资源锁后，得到该锁的事务1才能开始执行。
同样， 如果我们 这样设定执行的顺序来解决这样的问题，是不是会导致 线程相互等待的时间过长 而导致性能大幅降低呢 ？（ 如事务2 先执行，那么事务1就必须等待 事务2执行完后，释放对A 资源的锁后， 得到该锁的事务1 才能继续执行）
我们完全没必要有这种担忧， 原因很简单，大型系统中， 即便是在高并发状态下，两个或者多个不同线程的事务 能同时在千万条数据中 并发访问到（这里指 CUD 操作）完全相同的数据 的概率是相当小的 。
产生死锁的必要条件 虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件 。
1 ）互斥条件： 指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2 ）请求和保持条件： 指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3 ）不剥夺条件： 指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。（既是没有Timeout 或者 更高优先级剥夺 的情况）
4 ）环路等待条件： 指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···,Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
死锁的详细说明