问题描述
线上代码如下：
-
先加上一个数据库行锁
-
执行业务操作
-
最后释放这个行锁
@Transactional(rollbackFor = Exception.class)
void method(){
try{
add db lock
doBiz();
}finally{
release db lock
}
}
实际遇到了 doBiz() 导致OOM了，导致数据库行锁没有释放，结果其它用户执行method方法全部失败。
问题排查
首先如上代码因为一直以来都是好的，没有遇到问题，而报错是 **DUPLICATE KEY**错误（在add db lock方法中，拿个表设置了unique key，插入相同的会报错）。
另外因为线上是很多用户操作的。
所以：直接去arthas trace该方法，然后顺便去看doBiz()方法有没有重复加锁的逻辑，且doBiz()方法是耗时的；另外还去数据库看了是否锁加成功了，即数据库有没有记录。发现都没有
然后排查到的几个现象，这个时候还没有人准确看doBiz()的异常
-
联系dba查看可以看到很多加锁的sql操作在等待队列中
-
arthas trace 加锁报错了 MySQLTransactionRollbackException: Lock wait timeout exceeded，try restarting transaction
-
部分可以看到释放锁但是报错Communications link failure。
所以是加锁失败，然后又一直重试，一直失败。(所以去数据库查询的时候没有找到记录，然后因为很简单的sql，所以怀疑锁没有释放，去找重复加锁和释放锁为什么没有执行，结果原因在这里)。另外发现了释放锁有问题，则机器肯定也有问题了。
随后又看了机器的各个log，发现了OOM异常。所以结论是：在一个事务中，业务代码超时且OOM异常了，导致事务一直没有提交，等待锁超时，然后又一直重试。
随后改写代码加日志，验证猜想。所以这也说明平时日常工作中重要地方加日志的重要性质（然后走了一次机器发布重启，当时主要是排查也没有想到这个）
@Transactional(rollbackFor = Exception.class)
void method(){
try{
add db lock
doBiz();
}catch(Exception e){
logger.error("xxx", e)
}finally{
logger.warn("release lock");
release db lock
}
}
测试发现有测试例子是没有执行finally的释放锁方法的
顺便也说下OOM的问题，是select了数据库中的大字段，大量内存占用处，一般这个大纪录字段是单个记录才需要查询的； 当扫描了所有记录，且也select这个字段导致出现OOM。所以spring mybatis 结合查询的时候，不要什么时候都select所有字段。