接下来从几个方面介绍：
多线程死锁多线程死锁解决办法数据库死锁数据库死锁解决办法情况一： 死锁是两个或多个线程互相等待对方所有用的资源情形：现在有线程1和线程2。线程1执行过程中，先锁定了对象a，然后需要再锁定b才能继续执行代码；而线程2正巧相反，先锁定了b，需要再锁定a才能继续执行代码。这时，两个线程都等着对方解锁，才能继续执行，这时，两个线程就进入等待状态，最终不会有线程执行。这就变成了死锁。
接下来是代码实例：
class DeadLock implements Runnable{ boolean lockFormer; static Object o1 = new Object(); static Object o2 = new Object(); DeadLock(boolean lockFormer){ this.lockFormer = lockFormer; } @Override public void run() { if (this.lockFormer){ synchronized(o1){ try{ Thread.sleep(500); System.out.println("线程1"); }catch (Exception e){ e.printStackTrace(); } synchronized (o2){ System.out.println("lok"); } } }else { synchronized (o2){ try{ Thread.sleep(500); System.out.println("线程2"); }catch (Exception e){ e.printStackTrace(); } synchronized (o1){ System.out.println("lok"); } } } } }尽量避免加多个锁，避免死锁。
参考连接： http://www.importnew.com/30277.html#comment-795471 https://www.cnblogs.com/caoshenglu/p/9461567.html情况二： 线程池自己引发的死锁 单线程使用不当引发死锁，实现代码：
@Slf4j class DeadLock2 { public static void main(String[] args) { ExecutorService pool = Executors.newFixedThreadPool(10); pool.submit(() -> { try{ log.info("First"); pool.submit(() -> log.info("second")).get(); log.info("third"); }catch (InterruptedException | ExecutionException e){ log.error("Error",e); } }); System.out.println("process is over"); } }看起来没有什么问题-所有信息都按预期输出：
process is over 15:46:07.470 [pool-1-thread-1] INFO xiaowang.org.prictice.DeadLock2 - First 15:46:07.474 [pool-1-thread-2] INFO xiaowang.org.prictice.DeadLock2 - second 15:46:07.474 [pool-1-thread-1] INFO xiaowang.org.prictice.DeadLock2 - third注意我们用 get() 阻塞线程，在显示“Third”之前必须等待内部线程（Runnable）运行完成。这是个大坑！等待内部任务完成意味着需要从线程池额外获取一个线程来执行任务。然而，我们已经使用到了一个线程，所以内部任务在获取到第二个线程前将一直阻塞。当前我们的线程池足够大，运行没问题。让我们稍微改变一下代码，将线程池缩减到只有一个线程，另外关键的一点是我们移除 get() 方法：
@Slf4j class DeadLock2 { public static void main(String[] args) { ExecutorService pool = Executors.newFixedThreadPool(10); pool.submit(() -> { log.info("First"); pool.submit(() -> log.info("second")); log.info("third"); }); System.out.println("process is over"); } }代码运行正常，只是有点乱：
15:51:06.334 [pool-1-thread-1] INFO xiaowang.org.prictice.DeadLock2 - First 15:51:06.339 [pool-1-thread-2] INFO xiaowang.org.prictice.DeadLock2 - second 15:51:06.339 [pool-1-thread-1] INFO xiaowang.org.prictice.DeadLock2 - third顺序的改变完全在预料之内，没有涉及线程间的竞态条件（事实上我们只有一个线程）。仔细分析一下发生了什么：我们向线程池提交了一个新任务（打印“Second”的任务），但这次我们不需要等待这个任务完成。因为线程池中唯一的线程被打印“First”和“Third”的任务占用，所以这个外层任务继续执行，并打印“Third”。当这个任务完成时，将单个线程释放回线程池，内部任务最终开始执行，并打印“Second”。那么死锁在哪里？来试试在内部任务里加上 get() 方法：
只有一个线程， ExecutorService pool = Executors.newFixedThreadPool(1)
@Slf4j class DeadLock2 { public static void main(String[] args) { ExecutorService pool = Executors.newFixedThreadPool(1); pool.submit(() -> { try{ log.info("First"); pool.submit(() -> log.info("second")).get(); log.info("third"); }catch (InterruptedException | ExecutionException e){ log.error("Error",e); } }); System.out.println("process is over"); } }死锁出现了！我们来一步一步分析：
打印“First”的任务被提交到只有一个线程的线程池任务开始执行并打印“First”我们向线程池提交了一个内部任务，来打印“Second”内部任务进入等待任务队列。没有可用线程因为唯一的线程正在被占用我们阻塞住并等待内部任务执行结果。不幸的是，我们等待内部任务的同时也在占用着唯一的可用线程get() 方法无限等待，无法获取线程死锁方法一： 加锁顺序 当索格线程需要相同的锁，但按照不同的顺序加锁，死锁就很容易发生。 如果能确保所有的线程都是按照相同的顺序获取锁，那么死锁就不会发生，实例如下：
Thread 1: lock A Lock B Thread 2 : wait for A lock C (when A locked) Thread 3: wait for A wait for B wait for C如果一个线程（比如线程3）需要一些锁，那么必须按照确定的顺序获取锁。他只有获得了从顺序上排在前面的锁之后，才能获取后面的锁。
例如，线程2和线程3只有在获取了锁A之后才能尝试获取锁C。因为线程1已经拥有了锁A，所以线程2和3需要等到锁A被释放。然后他们尝试对B和C加锁之前，必须成功的对A加锁。
按顺序加锁是一种有效的死锁预防机制。但是，这种方式需要你事先知道所有可能会用到的锁，但总有些时候是无法预知的。
方法二： 加锁限时 另外一个避免死锁的方法，尝试获取锁时候加一个超时时间，这也意味着在尝试获取的过程中，若超过了这个时限，该线程则放弃对该锁的请求。若一个线程没有在给定的时间内获取到所需要的锁，则进行回退并释放所有以获得的锁，然后再等待一段随机时间再尝试。这段随机的等待时间，让其他线程有机会尝试获取相同的这些锁，并且让该应用再没有获得锁的时候可以继续进行。 实例如下：
Thread 1 locks A Thread 2 locks B Thread 1 attempts to lock B but is blocked Thread 2 attempts to lock A but is blocked Thread 1's lock attempt on B times out Thread 1 backs up and releases A as well Thread 1 waits randomly (e.g. 257 millis) before retrying. Thread 2's lock attempt on A times out Thread 2 backs up and releases B as well Thread 2 waits randomly (e.g. 43 millis) before retrying.在以上的例子中，线程2比线程1早200毫秒经行重试加锁，因此它可以先成功地获取到两个锁。这时，线程1尝试获取锁A并且处于等待状态。当线程2结束时，线程1也可以顺利的获得这两个锁（除非线程2或者其它线程在线程1成功获得两个锁之前又获得其中的一些锁）。
需要注意的是，由于存在锁的超时，所以我们不能认为这种场景就一定是出现了死锁。也可能是因为获得了锁的线程（导致其它线程超时）需要很长的时间去完成它的任务。
此外，如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。如果只有两个线程，并且重试的超时时间设定为0到500毫秒之间，这种现象可能不会发生，但是如果是10个或20个线程情况就不同了。因为这些线程等待相等的重试时间的概率就高的多（或者非常接近以至于会出现问题）。 (译者注：超时和重试机制是为了避免在同一时间出现的竞争，但是当线程很多时，其中两个或多个线程的超时时间一样或者接近的可能性就会很大，因此就算出现竞争而导致超时后，由于超时时间一样，它们又会同时开始重试，导致新一轮的竞争，带来了新的问题。)
这种机制存在一个问题，在Java中不能对synchronized同步块设置超时时间。你需要创建一个自定义锁，或使用Java5中java.util.concurrent包下的工具。写一个自定义锁类不复杂，但超出了本文的内容。后续的Java并发系列会涵盖自定义锁的内容。
方法三： 死锁检测 Jconsole是JDK自带的监控工具，在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM，对运行在Java应用程序的资源消耗和性能进行监控，并画出大量的图表，提供强大的可视化界面。而且本身占用的服务器内存很小，甚至可以说几乎不消耗。
我们在命令行中敲入jconsole命令，会自动弹出以下对话框，选择进程1362，并点击“链接” 进入所检测的进程后，选择“线程”选项卡，并点击“检测死锁”
假设我们有一张表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。
id:bigint token:varchar(30) message:varchar(4096)innodb对于主键使用密集索引，这是一种数据存储的方式，表数据是和主键一起存储，主键索引的叶子结点存储行数据。对于普通索引，其叶子结点存储的是主键值。
下面分析索引和锁的关系(在RC级别下)：
delete from msg where id = 2;
由于id是主键，因此直接锁住整行记录即可。
2. delete from msg where token = ‘cvs’; 由于token是二级索引，因此先锁住二级索引（两行），接着会锁住相应主键对应的记录； 3. delete from msg where message = ‘订单号是多少’; message没有索引，所以走的是全表扫描过滤。这时表上的各个记录都能将添加上X锁。
数据库的事务隔离级别：
未提交读（read uncommitted)已提交读（read committed）：能读到已经提交的数据。可重复读（repeatable read）：在同一个事务内查询都是事务开始时刻一致的，InnoDB默认级别.串行化（Serializable)我们较常用的是RC和RR. 如下图所示，事务A在第一次查询时得到1条记录，在第二次执行相同查询时却得到两条记录。从事务A角度上看是见鬼了！这就是幻读，RC级别下尽管加了行锁，但还是避免不了幻读。 innodb的RR隔离级别可以避免幻读发生，怎么实现？当然需要借助于锁了！
为了解决幻读问题，innodb引入了gap锁。
在事务A执行：update msg set message=‘订单’ where token=‘asd’;
innodb首先会和RC级别一样，给索引上的记录添加上X锁，此外，还在非唯一索引’asd’与相邻两个索引的区间加上锁。
这样，当事务B在执行insert into msg values (null,‘asd’,’hello’); commit;时，会首先检查这个区间是否被锁上，如果被锁上，则不能立即执行，需要等待该gap锁被释放。这样就能避免幻读问题。
情况一： 不同的表相同记录行锁冲突 这种情况很好理解，事务A和事务B操作两张表，但是出现循环等待情况。 情况二： 相同表记录行锁冲突 这种情况比较常见，之前遇到两个job在执行数据批量更新时，jobA处理的的id列表为[1,2,3,4]，而job处理的id列表为[8,9,10,4,2]，这样就造成了死锁。 情况三： 不同索引锁冲突 这种情况比较隐晦，事务A在执行时，除了在二级索引加锁外，还会在聚簇索引上加锁，在聚簇索引上加锁的顺序是[1,4,2,3,5]，而事务B执行时，只在聚簇索引上加锁，加锁顺序是[1,2,3,4,5]，这样就造成了死锁的可能性。 情况四： gap锁冲突 innodb在RR级别下，如下的情况也会产生死锁，比较隐晦。不清楚的同学可以自行根据上节的gap锁原理分析下。
