由事物隔离级别引发的血案

今天公司的系统发现一个bug：主表记录的已还款总额和还款记录表里面的偿还金额之和不一致。看到这个问题，我的第一反应是怀疑还款的时候离线锁没生效，导致并发修改主表记录。可是经过查看日志和代码，排除了这个可能性。然后又怀疑可能是由于还款之后，修改已还款总额和还款状态时只调用了jpa的save，没有flush，导致没及时写入数据库，别的线程更新的时候不是最新数据。但再一想，发现不对，因为还款的操作是在事务之中进行的，事务结束，jpa会自动把修改写入数据库，应该不会出现这个问题。后来请来大牛帮忙分析，终于发现了这个巨坑。。。。

先说一下代码结构

 1 @Transactional(value = Transactional.TxType.REQUIRES_NEW)
 2     public void repayInTranaction() {
 3         repay();
 4     }
 5     // 调用返回的时候，主表的修改才flush到数据库
 6
 7     private void repay() {
 8         try {
 9             lock.lock();
10             // 查询主表记录
11             // 插入还款记录，状态为待还款
12             // 还款
13             // 修改还款记录，状态为已成功
14             // 将该次还款金额加到主表的已还款总额，这个地方修改过后调用了save, 没有flush
15         } catch (Exception e) {
16             // error handling
17         } finally {
18             lock.unlock();
19         }
20     }

其中，repayInTransaction方法会被并发调用。

也许经验比较丰富的大牛看到这段示例代码立刻就能看出问题所在。是的，正如本文的标题所说，问题的关键就在于事务隔离。spring transaction的默认隔离级别（关于隔离级别，可参考http://blog.sina.com.cn/s/blog_539d361e0100ncf6.html）是“已提交读”，也就是说，如果一个事务修改了某一行数据，但尚未提交，此时另外一个事务来读取同一行是不能读取到第一个事务的修改的。

在上面的代码中，如果第一个线程执行完repay方法，但repayInTranaction方法尚未返回，这个时候lock已经释放，但事务尚未提交，新的线程创建了新的事务，要来修改同一条主表记录。由于锁已经释放，新线程可以执行到第10行的部分，读出第一个线程已经修改但尚未提交的数据。然后第一个线程提交第一个事务，接着第二个线程提交第二个事务，悲剧就发生了。。。

补救方法比较简单，修改一下代码结构，让锁的作用范围比事务的范围更大就ok了。修改后代码如下：

 1 public void repay() {
 2         try {
 3             lock.lock();
 4             repayInTranaction();
 5         } catch (Exception e) {
 6             // error handling
 7         } finally {
 8             lock.unlock();
 9         }
10     }
11
12     @Transactional(value = Transactional.TxType.REQUIRES_NEW)
13     public void repayInTranaction() {
14             // 查询主表记录
15             // 插入还款记录，状态为待还款
16             // 还款
17             // 修改还款记录，状态为已成功
18             // 将该次还款金额加到主表的已还款总额，这个地方修改过后调用了save, 没有flush
19     }