并行 Stream 与 Spring 事务相遇?不是冤家不聚头

开发 前端
本篇文章讲述的Bug虽然简单,但如果不了解parallelStream与@Transactional注解的特性,还是很难排查的。而且也让我们意识到,虽然Spring通过@Transactional将事务管理进行了简化处理,但作为开发者,还是需要深入了解一下它的基本运作原理。

[[437152]]

本文转载自微信公众号「程序新视界」,作者二师兄  。转载本文请联系程序新视界公众号。

今天这篇文章跟大家分享一个实战中的Bug及解决方案和技术延伸。

事情是这样的:运营人员反馈,通过Excel导入数据时,有一部分成功了,有一部分未导入。初步猜测,是事务未生效导致的。

查看代码,发现导入部分已经通过@Transcational注解进行事务控制了,为什么还会出现事务不生效的问题呢?

下面我们就进行具体的案例分析,Let's go!

事务不生效的代码

这里写一段简单的伪代码来演示展示一下事务不生效的代码:

  1. @Transactional(rollbackFor = Exception.class) 
  2. ublic void batchInsert(List<Order> list) { 
  3. list.parallelStream().forEach(order -> orderMapper.save(order)); 

逻辑很简单,遍历list,然后批量插入Order数据到数据库。在该方法上使用@Transactional来声明出现异常时进行回滚。

但事实情况是,其中某一条数据执行异常时,事务并没有进行回滚。这到底是为什么呢?

下面一探究竟。

JDK 8 的Stream

上面代码中涉及到了两个知识点:parallelStream和@Transactional,我们先来铺垫一下parallelStream相关知识。

在JDK8 中引入了Stream API的概念和实现,这里的Stream有别于 InputStream 和OutputStream,Stream API 是处理对象流而不是字节流。

比如,我们可以通过如下方式来基于Stream进行实现:

  1. List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);  
  2. numbers.stream().forEach(num->System.out.println(num)); 
  3.  
  4. 输出:1 2 3 4 5 6 7 8 9 

代码看起来方便清爽多了。关于Stream的基本处理流程如下:

jdk8 Stream

在这些Stream API中,还提供了一个并行处理的API,也就是parallelStream。它可以将任务拆分子任务,分发给多个处理器同时处理,之后合并。这样做的目的很明显是为了提升处理效率。

并行处理

parallelStream的基本使用方式如下:

  1. // 并行执行流 
  2.  
  3. list.stream().parallel().filter(e -> e > 10).count() 

针对上述代码,对应的流程如下:

parallelStream流程图

而parallelStream会将流划分成多个子流,分散到不同的CPU并行处理,然后合并处理结果。其中,parallelStream默认是基于ForkJoinPool.commonPool()线程池来实现并行处理的。

通常情况下,我们可以认为并行会比串行快,但还是有前提条件的:

  • 处理器核心数量:并行处理核心数越多,处理效率越高;
  • 处理数据量:处理数据量越大优势越明显;

但并行处理也面临着一系列的问题,比如:资源竞争、死锁、线程切换、事务、可见性、线程安全等问题。

@Transactional事务处理

上面了解了parallelStream的基本原理及特性之后,再来看看@Transactional的事务处理特性。

@Transactional是Spring提供的基于注解的一种声明式事务方式,该注解只能运用到public的方法上。

基本原理:当一个方法被@Transactional注解之后,Spring会基于AOP在方法执行之前开启一个事务。当方法执行完毕之后,根据方法是否报错,来决定回滚或提交事务。

在默认代理模式下,只有目标方法由外部方法调用时,才能被Spring的事务拦截器拦截。所以,在同一个类中的两个方法直接调用,不会被Spring的事务拦截器拦截。这是事务不生效的一个场景,但在上述案例中,并不存在这种情况。

Spring在处理事务时,会从连接池中获得一个jdbc connection,将连接绑定到线程上(基于ThreadLocal),那么同一个线程中用到的就是同一个connection了。具体实现在DataSourceTransactionManager#doBegin方法中。

Bug综合分析

在了解了parallelStream和@Transactional的相关知识之后,我们会发现:parallelStream处理时开启了多线程,而@Transactional在处理事务时会(基于ThreadLocal)将连接绑定到当前线程,由于@Transactional绑定管理的是主线程的事务,而parallelStream开启的新的线程与主线程无关。因此,事务也就无效了。

此时,将parallelStream改为普通的stream,事务可正常回滚。这就提示我们,在使用基于@Transactional方式管理事务时,慎重使用多线程处理。

问题拓展

虽然parallelStream带来了更高的性能,但也要区分场景进行使用。即便是在不需要事务管理的情况下,如果parallelStream使用不当,也会造成同一时间对数据库发起大量请求等问题。

因此,在stream与parallelStream之间进行选择时,还要考虑几个问题:

  • 是否需要并行?数据量比较大,处理器核心数比较多的情况下才会有性能提升。
  • 任务之间是否是独立的,是否会引起任何竞态条件?比如:是否共享变量。
  • 执行结果是否取决于任务的调用顺序?并行执行的顺序是不确定的。

小结 

本篇文章讲述的Bug虽然简单,但如果不了解parallelStream与@Transactional注解的特性,还是很难排查的。而且也让我们意识到,虽然Spring通过@Transactional将事务管理进行了简化处理,但作为开发者,还是需要深入了解一下它的基本运作原理。不然,在排查bug时,很容易抓瞎。

 

责任编辑:武晓燕 来源: 程序新视界
相关推荐

2015-09-29 14:13:27

2009-12-03 11:23:29

冤家聚头金山360

2010-10-25 09:48:21

微软谷歌云计算

2018-08-16 10:18:21

公有云用户云厂商

2022-05-20 10:20:17

Spring事务MyBatis

2018-11-16 15:35:10

Spring事务Java

2023-04-03 10:24:00

spring事务场景

2020-11-02 17:26:20

人工智能机器学习技术

2010-08-16 12:58:35

AndroidJavaDalvik

2009-07-23 13:30:46

JDBC事务

2020-10-19 11:05:17

SpringTransaction事务

2011-09-15 12:13:42

乔布斯苹果

2019-03-19 17:00:11

区块链区块链技术司法

2009-06-22 09:01:57

Spring声明式事务

2023-10-12 08:29:06

线程池Java

2022-06-10 12:38:07

物联网IOT

2024-02-26 07:29:09

DevOpsTestOps编排

2021-10-29 07:49:22

Spring事务管理

2009-06-29 17:54:47

Spring事务隔离

2022-02-14 16:53:57

Spring项目数据库
点赞
收藏

51CTO技术栈公众号