仔细思考之后，发现只需要赔6w。

你好呀，我是why。

上周发了《几行烂代码，我赔了16万》 16w 这篇文章之后，有不下十个朋友来找我，问我一些文章中的问题。

因为至少有一大批人看了文章之后，在我没有提供源码的情况下，自己搭建了环境，然后把项目跑起来，并去验证了文章中的一些观点。

我没有提供源码，主要是因为我觉得都是非常简单的 Demo 级别的代码，但是我会把思路讲的非常清楚。

所以我觉得，你要是真心想深入了解一下，花个半小时就能按照文中的描述，把项目跑起来。

别懒，好嘛，自己多动动手，是很有收益的事情的。

什么，你问我为什么不愿意花半小时把代码放到 git 上去？

那不是因为我懒嘛。

另外，经过朋友提醒，我发现，其实我只需要亏 6w 啊：

最最后，我又发现，这特么不是我假设的场景吗。其实我一分钱都不需要赔呀。

好了，本文就顺着前面的文章接着往下说。

前情提要

为了让新老朋友快速入戏，先给大家简单的做一个前情提要。但是我还是强烈建议你去看前一章，以做到无缝衔接。

怎么样，有没有发条张内味，懂的都懂，不多解释。

首先，我们有这样的一份代码：

逻辑概述起来很简单：

• 0.加锁
• 1.查询库存。
• 2.判断是否还有库存。
• 3.有库存则执行减库存,创建订单的逻辑。
• 4.没有库存则返回。
• 5.释放锁

但是这个方法上还加了一个 @Transactional 注解，坏就坏在这个注解上。

假设我们模拟 1000 个人来抢库存：

在 MySQL 的默认隔离级别下，如果我们的库存是 10 个，那么程序执行完成后，我们的订单表必然是 20 个，一个不多一个不少。

就是天王老子来了，它也是 20 个，不会变。

为什么是 20 个？

先回答一个很多同学都关心的问题。

为什么订单数总是 20 ？

关于这个 20，就很微妙了。

通过下面我截取的一部分日志也能观察出来一个很奇怪的现象：

首先，我们看加锁和释放锁的过程，其实是没有问题的。

都踩在正确的节点上：加锁->释放->加锁->释放...

没有任何毛病。

问题出在库存上的，把上面的图画的细一点，就是这样的：

线程 Thread-11 虽然对库存进行了减一的操作，但是事务并没有提交。所以，Thread-107 能读库存为 2。

这一点在上一篇文章着重分析过，不再赘述。

因此连续两个库存为 2 ，就是这样的来的。

那么 Thread-46 为什么读不到库存为 2 呢？

这是一个关键的问题。

Thread-46 读到的一定是它前面的第两个线程，也就是 Thread-11 的事务提交之后的库存，也就是 1。

是的，我这里没有写错，就是前面第两个。

有的同学说不对啊，根据你上面的图，Thread-46 完全有可能在 Thread-107 释放锁之后，赶在 Thread-11、Thread-107 提交事务之前做数据库查询的操作呀？

比如在上面的图片中加入四个时刻：

由于是多线程的情况，它们之间的关系完全有可能是这样的：

首先，T2 时刻肯定是先于 T3 和 T4 的，因为只有释放了锁之后才能触发当前事务的提交操作，和其他线程的加锁操作。

T1 时刻和 T3 时刻之间是没有先后顺序的，因为这两个事务的提交说不准谁先谁后。

但是 T4 时刻完全有可能是先于 T3 和 T1 时刻的，在这两个事务提交之前，抢先执行了查询库存的操作。

也就是说，虽然前两个线程都扣减库存了，但是还没提交事务，这个时候 T3 时刻读取到的库存理论上还是为 2 吧？

对不对？

你别说，仔细一想还挺有道理的。

但是，朋友，我告诉你。

• T2 时刻一定是晚于 T1 时刻的。
• T3 时刻一定是晚于 T1 时刻的。
• T4 时刻一定是晚于 T1 时刻的。
• T3 时刻和 T4 时刻，推导不出必然的先后关系。但是一定都晚于 T2 时刻。

你别看这么轻飘飘的四行字，我硬是把自己给绕进去了，想了整整一个下午，然后又写了各种各样的代码去验证它们的正确性，生怕自己给搞错了。

接下来我们一个个的说：

T3 时刻一定是晚于 T1 时刻的。

能执行 T3 时刻的事务提交操作，那么必然已经完成了 T2 时刻的释放锁的操作。

按照前面画的线程图，如果完成了释放锁的操作，那么必然完成了扣减库存的操作。

这个没毛病，对吧？

关键节点就在于扣减库存的这个操作。

对应下面这个 sql：

UPDATE product set product_count=product_count-1 where id=1;

有没有悟出点什么。

如果你还没反应过来，我提个醒：

在数据库的 RR 隔离级别下，上面这个 sql 上的是什么锁？

是不是加的行锁？

而这个 sql 要成功执行的先决条件是什么？

是不是要前一个线程把行锁给释放了？

而前一个线程什么时候释放行锁？

是不是要等到事务提交的时候？

等等，前一个线程事务提交的时候，这不就是 T1 时刻吗？

由此可得，T3 时刻一定是晚于 T1 时刻的。

而关于 T4 时刻为什么一定晚于 T1 时刻，其实就很好理解了。

只有 Thread-107 线程释放锁之后，即 T2 时刻之后，Thread-46 线程才能获取到锁。

那么按照我们前面的推理，T2 时刻，一定是在 T1 时刻之后。

根据传导性，T4 时刻一定晚于 T1 时刻。

而根据多线程的特性，T2 释放锁之后，有可能执行提交事务的逻辑，即 T3。

也有可能被挂起，然后程序先执行到了 T4。

所以，T3 时刻和 T4 时刻，推导不出必然的先后关系。但是一定都晚于 T2 时刻。

而 T3 时刻，不管是提交之前还是之后，此时的库存一定已经是 1 了，因为 T1 已经提交了事务。

同理，T4 时刻，不管是在 T3 时刻之前还是之后执行，它读取到的库存，一定是 T1 时刻提交事务之后的库存。

所以，你再看我前面这句话，你就能理解了：

Thread-46 读到的一定是它前面的第两个线程，也就是 Thread-11 的事务提交之后的库存，也就是 1。

而纵观整个日志，你会发现日志中库存按照顺序打印是这样的：

我前面给你解释了 2->2->1 的这个流程，所以你应该能按照这个思路推断出整流程了。

也就能明白，为什么就算是天王老子来了，它也必须得是 20 单。

如果上面把你看懵了，没关系，你就记住一句话：

由于操作的是同一条数据库数据，因为行锁的存在，导致线程的阻塞，会出现排队现象。

接着，我再说一下，我写文章的时候把我绕了很久，甚至把我绕进去了的一个逻辑。

最开始，我在图上标记时刻的时候是这样的：

我就在想，T3 时刻会不会也读到库存为 2 呢？

为什么不能呢？

在极端情况下，T1、T2 都被阻塞了，都没有提交，T3 时刻完全有可能读到库存为 2 呀？

比如，我在程序里面使用编程式事务，让两个线程在提交事务之前，先睡眠一下。

然后我在数据库工具里面直接执行查询库存的操作，查出来的应该是 2 呀。

后来，我说服了自己，我觉得这是有可能的，极端的情况下会出现这样的情况。

而这样的情况一出现，订单就可能会大于 20 了，推翻我之前的观点。

我觉得理论是可行的，已经做好重写的准备了，只需要模拟一下这个极端场景就行了。

于是我写了一份代码出来，然后调试了 10 分钟，都没有看到想要的现象。

我心想，这现象还真特么奇怪又极端。

又调了 10 分钟，发现还是不行。

我就停下来，开始扣脑袋了。

才猛然的发现一个真理：能到 T2 时刻提交事务，那么 T1 时刻必然已经执行完成。因为 T1 和 T2 之间还有一个扣减库存的数据库操作，有行锁，所以必须要等待 T1 提交才能执行。

也就是说：不可能出现 T1,T2 都被阻塞的情况。

前面的假设不成立。

我写这个小片段的意思就是：

实践是检验真理的唯一标准。

看一眼行锁

前面说了这么多行锁，现在我就带你亲眼看看这个神奇的玩意。

首先，我们在 MySQL 工具里面执行这个 SQL，模拟事务开启，但是还没有提交的状态：

这时用这条 sql 可以查询到当前的锁信息如下：

select * from information_schema.innodb_trx;

需要说明的是，查询信息字段并没有截全。

这个时候，发起程序调用：

你会发现，程序就卡在更新语句的地方，走不动了。

为啥？

还能为啥，锁住了呗。

再看一下当前的锁的情况：

多了一条叫 LOCK_WAIT 状态的数据，在等待前一个正在跑的事务提交锁。

所以从程序的角度来看，就是阻塞在这里了。

而大家经常在各大秒杀相关的文章里面都能看到这这句 SQL：

UPDATE product set product_count=product_count-1 where id=1 and product_count>0;

同样的道理，用这条 SQL 来进行兜底，假设只有一个库存了，有 100 个线程都读到了这一个库存，然后来同时执行这个 SQL，也保证绝对不会出现超卖的情况。

因为到 MySQL 层面，它会帮我们保证，只会有一个线程执行成功返回更新的条数为 1，其他的都是 0。

程序里面控制，为 1 才能算秒杀成功。

MySQL 层面，说具体点就是锁。

再说具体一点，就是行锁。

当然了，表锁也能保证，但是这种情况，为什么不优化为行锁呢？

好了，我们接着说阻塞。

注解上的超时时间

说到程序阻塞，随之而来的另一个问题就出现了

这是什么意思：

@Transactional(timeout = 3)

意思很明显嘛，就是被这个注解修饰了的方法执行时间不能超过三秒嘛。

比如这样，在事务的方法里面，睡眠 4 秒，那么这个方法的总执行时间大于了 3 秒，所以事务就会被回滚：

上面这个方法会抛出事务超时的异常，对不对？

对个锤子对！

我给你跑一下：

并没有出任何问题吧。

足以证明， @Transactional 上的 timeout 参数并不是控制整个方法的。

那控制的是什么呢？

我在上面的代码中在加入一行，就会出现这样的异常：

这是为什么呢？

我们从源码中寻找答案。

根据异常堆栈，可以定位到这一个方法：

org.springframework.transaction.support.ResourceHolderSupport#checkTransactionTimeout

而该方法，判断如果超时了则设置 rollbackOnly 标志为 true，然后抛出异常：

怎么判断是否超时呢？

org.springframework.transaction.support.ResourceHolderSupport#getTimeToLiveInMillis

用 deadline 的时间和当前时间做减法，如果 deadline 小于当前时间了，则说明该事务已经超时了。

所以问题就变成了两个：

• 1.谁在调用判断的逻辑？
• 2.deadline 哪来的？

先看第一个问题。

Mybatis 里面有这样的一个方法：

org.apache.ibatis.executor.SimpleExecutor#prepareStatement

prepare，准备阶段。

就是在执行 SQL 之前获取当前连接的超时时间。

而获取超时时间的逻辑里面就包含了校验当前是否超时的方法。

如果超时就设置 rollbackOnly 标识，然后抛出异常。

如果不超时则返回配置的超时时间，表示这个 SQL 语句运行可以执行的最长时间。

再看看第二个问题：deadline 哪来的？

查看该字段被调用的地方，可以看到有一个 setTimeoutInMillis 方法：

再找到该方法被调用的地方，我们就熟悉了：

org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin

这不就是我之前文章里面着重分析的部分嘛：

所以，timeout 参数开始生效是什么时候呢？

是事务就绪的那一刻。

所以，回到这个代码中，为什么加入一行查询的 SQL 语句，事务方法就抛出了超时异常呢？

因为触发了超时时间检查的逻辑。

综上，关于超时的流程图应该是这样的：

最后，再演示一下 SQL 阻塞住之后，导致超时的效果。

首先，我们先在 MySQL 的工具中，开启事务，执行 SQL，对这条记录加上行锁：

然后，再次执行代码：

可以看到三秒之后，抛出了异常：

MySQLTimeoutException: Statement cancelled due to timeout or client request

这波，不需要我分析原因了吧？

最后说一句（求关注）

好了，看到了这里安排个“一键三连” （转发、在看、点赞） 吧，写文章很累的，需要一点正反馈。