本文转载自微信公众号《程序新视界》，作者为二师兄。转载本文请联系程序新视界公众号。今天的文章给大家分享一个实战中的bug、解决方法和技术延伸。事情是这样的：操作人员反映，通过Excel导入数据时，有的成功了，有的不成功。初步猜测是交易没有生效。查看代码，发现import部分已经被@Transcational注解控制了。为什么还会出现交易不生效的问题？接下来，我们将进行具体的案例分析。我们走吧！这里写一个简单的假代码来演示显示事务不生效的代码：@Transactional(rollbackFor=Exception.class)ublicvoidbatchInsert(Listlist){list.parallelStream().forEach(order->orderMapper.save(order));逻辑很简单，遍历列表，然后将订单数据批量插入数据库。在此方法上使用@Transactional以在发生异常时声明回滚。但事实是当一条数据执行异常时，事务并没有回滚。为什么是这样？找出下面。上面JDK8的Stream代码涉及两个知识点：parallelStream和@Transactional。先铺垫一下parallelStream的知识。StreamAPI的概念和实现是在JDK8中引入的。这里的Stream不同于InputStream和OutputStream。StreamAPI处理对象流而不是字节流。比如我们可以基于Stream实现，如下：Listnumbers=Arrays.asList(1,2,3,4,5,6,7,8,9);numbers.stream()。forEach(num->System.out.println(num));输出：123456789代码看起来更加方便和清爽。Stream的基本处理流程如下：在这些StreamAPI中，jdk8Stream还提供了一个并行处理API，即parallelStream。它可以将任务拆分成子任务，分发给多个处理器同时处理，然后合并。这样做的目的显然是为了提高处理效率。并行处理parallelStream的基本用法如下：//并行执行流list.stream().parallel().filter(e->e>10).count()对于上面的代码，对应的流程如下：parallelStream流程图，parallelStream将流分成多个子流，分发给不同的CPU进行并行处理，然后合并处理结果。其中，parallelStream默认基于ForkJoinPool.commonPool()线程池实现并行处理。一般情况下，我们可以认为并行比串行快，但还是有前提的：处理器核心数：并行处理的核心数越多，处理效率越高；处理的数据量：处理的数据量越大，优势越明显；但是并行处理也面临着一系列的问题，比如：资源竞争、死锁、线程切换、事务、可见性、线程安全等问题。@Transactional事务处理在了解了上面parallelStream的基本原理和特点之后，我们再来看看@Transactional的事务处理特点。@Transactional是Spring提供的一种基于注解的声明式事务方法，只能应用于公共方法。基本原理：当一个方法被@Transactional注解时，Spring会在该方法执行前启动一个基于AOP的事务。方法执行后，根据方法是否报错决定回滚或提交事务。在默认的代理模式下，只有当目标方法被外部方法调用时，才能被Spring的事务拦截器拦截。所以同一个类中的两个方法直接调用，不会被Spring的事务拦截器拦截。这是交易不生效的场景，但是在上面的案例中，这个是不存在的。Spring在处理一个事务时，会从连接池中获取一个jdbc连接，并将该连接绑定到一个线程（基于ThreadLocal），然后在同一个线程中使用同一个连接。具体实现在DataSourceTransactionManager#doBegin方法中。Bug综合分析了解了parallelStream和@Transactional的相关知识后，我们会发现parallelStream处理时开启了多线程，而@Transactional在处理事务时会（基于ThreadLocal）将连接绑定到当前线程，因为@Transactional绑定管理主线程的事务，parallelStream新开的线程与主线程无关。因此，交易无效。此时将parallelStream改成普通流，事务就可以正常回滚了。这提醒我们在管理基于@Transactional的事务时要谨慎使用多线程。问题拓展parallelStream虽然带来了更高的性能，但是应该在不同的场景下使用。即使在不需要事务管理的情况下，如果parallelStream使用不当，也会造成同时向数据库发出大量请求。因此，在选择stream和parallelStream时，需要考虑几个问题：是否需要并行？只有当数据量比较大，处理器核数比较多的时候，性能才会提高。这些任务是独立的吗？它们会导致任何竞争条件吗？例如：变量是否共享？执行结果是否取决于任务的调用顺序？并行执行的顺序未定义。小结本文描述的bug虽然简单，但是如果不了解parallelStream和@Transactional注解的特点，还是很难排查的。而这也让我们意识到，虽然Spring通过@Transactional简化了事务管理，但是作为开发者，我们还是需要深入了解它的基本运行原理。不然在排bug的时候很容易瞎了眼。
