代码原运行与Oracle数据上，后切换到MySQL。
测试发现，存在死锁问题，且遇到死锁直接报错，并没有等待数据库默认的50S超时时间。
Caused by:
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException:
Deadlock found when trying to get lock; try restarting transaction
起初以为是不是超时时间被人改了？
查看后发现并没有改变。
SHOW global VARIABLES LIKE 'innodb_lock_wait_timeout';
后来了解到mysql在5.7以后增加了innodb_deadlock_detect这个全局变量，默认为ON。这个变量用于控制MySQL是否主动检测死锁。
死锁检测的原理是构建一个以事务为顶点，锁为边的有向图，判断有向图是否有环，如有，即死锁。
检测到死锁后，会选择插入更新或删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
遇此次，遇到死锁后未等待超时时间，直接返回的原因估计就是它了。
总结：
MySQL有两种死锁处理方式：
1、innodb_lock_wait_timeout，设置超时时间，默认50S。
2、开启死锁检测，如果检测到回滚一条事务，继续其他事务。
但死锁检测的做法有一个性能问题：
对比的时间复杂度是O(n)。如果有1000个正在执行的线程，就存在100w次的对比，消耗CPU资源极大。
有博主做过压测，开启死锁检测大约存在5%左右的性能损耗。
在刚开始也想过死锁是否和事务隔离级别有关系，当时使用的RR级别，后来在官方文档看到一句话
The possibility of deadlocks is not affected by the isolation level,
because the isolation level changes the behavior of read operations,
while deadlocks occur because of write operations.
https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlocks.html
至于死锁的原因，通过explain发现，很可能是某句造成了全表扫描，进而造成了表锁。