Mybatis-update - 数据库死锁 - 获取数据库连接池等待

最近学习测试mybatis，单个增删改查都没问题，最后使用mvn test的时候发现了几个问题：

1. update失败，原因是数据库死锁
2. select等待，原因是connection连接池被用光了，需要等待

get:

1. 要勇于探索，坚持就是胜利。刚看到错误的时候直接懵逼，因为错误完全看不出来，属于框架内部报错，在犹豫是不是直接睡觉得了，毕竟也快12点了。最后还是给我一点点找到问题所在了。
2. 同上，要敢于去深入你不了解的代码，敢于研究不懂的代码。
3. 距离一个合格的码农越来越远了，因为越学越觉得漏洞百出，自己的代码到处都是坑。所以，一定要记录下来。

下面记录这两个问题。

1.mysql数据库死锁

这里，感谢http://www.cnblogs.com/lin-xuan/p/5280614.html，我找到了答案。在这里，我还是重现一下：

数据库死锁是事务性数据库 (如SQL Server, MySql等)经常遇到的问题。除非数据库死锁问题频繁出现导致用户无法操作，一般情况下数据库死锁问题不严重。在应用程序中进行try-catch就可以。那么数据死锁是如何产生的呢？

InnoDB实现的是行锁 (row level lock)，分为共享锁 (S) 和 互斥锁 (X)。

• 共享锁用于事务read一行。
• 互斥锁用于事务update或delete一行。

当客户A持有共享锁S，并请求互斥锁X；同时客户B持有互斥锁X，并请求共享锁S。以上情况，会发生数据库死锁。

如果还不够清楚，请看下面的例子。

双开两个mysql客户端

客户端A：

开启事务，并锁定共享锁S 在id=12的时候：

mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM blog WHERE id = 12 LOCK IN SHARE MODE;
+----+-------+-----------+
| id | name  | author_id |
+----+-------+-----------+
| 12 | testA |        50 |
+----+-------+-----------+
1 row in set (0.00 sec)

客户端B:

开启事务，尝试删除id=12:

mysql> START TRANSACTION;
Query OK, 0 rows affected (