还记得我们批量插入的耗时吗？

73791ms。

从 73791ms 到 15719ms。快了 58s 的样子。

已经非常不错了。

那么如果是某个线程抛出了异常呢？比如这样：

我们看看日志输出：

通过日志分析，看起来也是符合要求的。

而从读者反馈的实际测试效果来看，也是非常显著的：

真的符合要求吗？

符合要求，只是看起来而已。

经验老道的读者朋友们肯定早就看到问题所在了。已经把手举得高高的：老师，这题我知道。

我之前说了，这个实现方式实际上就是编程式事务配合二阶段提交（2PC）使用。

破绽就出在 2PC 上。

就像我和读者讨论这样的：

不能再往后扯了，再往后就是 3PC，TCC，Seata 这一套分布式事务的东西了。

这套东西写下来，就得上万字了。所以我从海神那边转了一篇文章，放在第二条推送里面了。如果大家有兴趣的可以去看一下。干货满满。

其实当我们把一个个子线程理解为微服务中的一个个子系统的时候，这就是一个分布式事务的场景了。

而我们拿出来的解决方案，并不是一个完美的解决方案。

虽然，从某种角度上，我们绕开了事务的隔离性，但是有一定概率出现数据一致性问题，虽然概率比较小。

所以我称之为这种方案叫做：基于运气编程，用运气换时间。

注意事项

关于上面的代码，其实还有几个需要注意的地方。

给大家提个醒。

第一个：启用多少线程进行分配数据插入，这个参数是可以进行调整的。

比如我修改为 10 个线程，每个线程插入 5w 条数据。那么执行时间又快了 2s：

但是一定记得不是越大越好，同时记得调整数据库连接池的最大连接数。不然白搭。

第二个：正是因为启动多少线程是可以进行调整的，甚至是可以每次进行计算的。

那么必须要注意的一个问题是不能让任何一个任务进入队列里面。一旦进入队列，程序立马就凉。

你想，如果我们需要开启 5 个子线程，但是核心线程数只有 4 个，有一个任务进入队列了。

那么这 4 个核心线程会一直阻塞住，等待主线程唤醒。

而主线程这个时候在干什么？

在等 5 个线程的运行结果，但是它只能收集到 4 个结果。

所以它会一直等下去。

第三个：这里是多个线程开启了事务在往表里插入数据，谨防数据库死锁。

第四个：注意程序里面的代码，countDown 安装标准写法上是要放到 finally 代码块里面的，我这里为了截图的美观度，省去了这个步骤：

你如果真的要用，得注意一下。而且这个finally你得想清楚了写，不是随便写的。

第五个：我这里只是提供一个思路，而且它也根本不是什么多线程事务。

也再次证明了，多线程事务就是一个伪命题。

所以我给出一个基于运气的伪一致性的回答也不过分吧。

第六个：多线程事务换个角度想，可以理解为分布式事务。，可以借助这个案例去了解分布式事务。但是解决分布式事务的最好的方法就是：不要有分布式事务！

而解决分布式事务的绝大部分落地方案都是：最终一致性。

性价比高，大多数业务上也能接受。

第七个：这个解决方案你要拿到生产用的话，记得先和业务同事沟通好，能不能接受这种情况。速度和安全之间的两难抉择。

同时自己留好人工修数的接口：

最后说一句

才疏学浅，难免会有纰漏，如果你发现了错误的地方，可以在留言区提出来，我对其加以修改。 感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

我是 why，一个被代码耽误的文学创作者，不是大佬，但是喜欢分享，是一个又暖又有料的四川好男人。

还有，欢迎关注我呀。