一、问题&分析
性能优化是技术人的永恒话题,当我们遇到性能问题时,你的第一反应是什么?
数据库索引优化,缓存优化,算法优化?
但,有时性能杀手往往就是性能优化引入的。
1.1. 案例
今天一大早,小艾刚到公司便收到一组系统报警,原来有一个接口报了一堆的慢情况。仔细排查,发现是前两天为服务域提供的一个订单的查询接口,该接口刚上线不久,正处于放量阶段,小艾立即惊出一身冷汗,不会是数据库出现了 慢SQL?记得上线前通过 explain 指令对 sql 进行过分析,明确已经使用了数据库索引。他赶紧打开阿里云控制台,快速进入 慢查询功能进行查看,但奇怪的是监控显示没有一条 慢查询,真是太诡异了。
还好不是数据库慢查询,不然可能存在将整个 MySQL 数据库拖垮的可能,小艾的悬着的心也终于放了下来。
可问题出在哪里呢?
这个查询接口非常简单,示例代码如下:
@GetMapping("getOrdersByUsers")
public RestResult<List<OrderVO>> allOrderByUsers(@RequestParam List<Long> users){
Stopwatch stopwatch = Stopwatch.createStarted();
List<Order> orders = getByUserId(users);
List<OrderVO> orderVOS = orders.stream()
.map(order -> OrderVO.applyByParallel(order))
.collect(Collectors.toList());
log.info("get order by user cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
return RestResult.success(orderVOS);
}
逻辑简单到令人发指,只有两步:
- 根据传入的 user id 从数据库中查询订单
- 将查询的 Order 转换为 OrderVO 返回用户
小艾,仔细观察这个接口,发现一个现象:当入参较多时,接口的性能变的非常差。
这个也比较好理解,系统使用的是 in 语句对数据进行查询,示例:select * from order_info where user_id in (?),当入参数据量非常大时,sql 执行耗时变高。这可能是一个原因,但MySQL 慢请求中未记录任何信息,说明 sql 的执行时间没有超过 1 秒,所以,这个只是一个表因。
为了更好的验证猜想,小艾对日志进行完善,整体如下:
@GetMapping("getOrdersByUsers")
public RestResult<List<OrderVO>> allOrderByUsers(@RequestParam List<Long> users){
Stopwatch stopwatch = Stopwatch.createStarted();
List<Order> orders = getByUserId(users);
log.info("get data from DB cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
stopwatch = Stopwatch.createStarted();
List<OrderVO> orderVOS = orders.stream()
.map(order -> OrderVO.applyByParallel(order))
.collect(Collectors.toList());
log.info("convert to OrderVO cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
return RestResult.success(orderVOS);
}
选了几个订单较多的用户进行测试,打印日志如下:
图片
好奇怪,数据库操作耗时有限,但 Order 向 OrderVO 的转换居然耗时这么多,真是太不可思议!
1.2. 问题分析
很明显是转化这步出了问题,其核心代码如下所示:
// 使用 Stream 流进行类型转化
List<OrderVO> orderVOS = orders.stream()
.map(order -> OrderVO.applyByParallel(order))
.collect(Collectors.toList());
// Order 到 OrderVO 的转化逻辑
public static OrderVO applyByParallel(Order order){
OrderVO orderVO = new OrderVO();
orderVO.setId(order.getId());
orderVO.setUserId(order.getUserId());
orderVO.setStatus(OrderStatus.parallelParseByCode(order.getOrderStatus()));
orderVO.setOrderType(OrderType.parallelParseByCode(order.getOrderType()));
orderVO.setProductType(ProductType.parallelParseByCode(order.getProductType()));
orderVO.setPromotionType(PromotionType.parallelParseByCode(order.getPromotionType()));
return orderVO;
}
// 将 Code 转换为对应的枚举
public static OrderStatus parallelParseByCode(int code) {
return Stream.of(values())
.parallel()
.filter(status -> status.getCode() == code)
.findFirst()
.orElse(null);
}
看完核心代码,请思考几分钟,问题可能出现在哪里?
- Stream 操作?Stream 比 for 循环性能超差些,但还不至于有这么大差异
- 反射、BeanCopy?核心代码没有使用这些 API,乖乖的进行 Coding
那问题究竟在哪?答案是 Stream 的 parallel() 函数。使用 parallel 函数最初的目标便是提升性能,为什么在这里却成了性能杀手?在解答前,先快速了解下这个函数:
`Stream.parallel()` 函数是 Java 8 中引入的新特性,底层采用了 Fork/Join 框架来实现并行处理。当你调用 `parallel()` 函数时,实际上是将流的并行性设计为 true。这意味着所进行的任何操作,如 `map` 或 `filter`,都是在并行流(parallel stream)上执行的。Fork/Join 框架首先会将一个大任务拆分成若干个小任务(Fork),然后分别对这些小任务进行处理,最后将得到的结果合并(Join)来得到最终结果。
这种方式能有效地将任务进行了分解,使得每个线程都可以独立地处理一部分任务,从而发挥了多核 CPU 的优势,提高了整体的处理效率。
从上述解释中可以看出,parallel 底层使用 Fork/Join 框架,对任务进行拆解,可以发挥多核的优势,那怎么就成了性能杀手呢?
先看下 Fork/Join 的整体执行流程:
图片
其执行主要分为以下几个阶段:
- 分割阶段(Fork Phase):将大任务拆分成若干个小任务,直到任务的规模足够小,可以直接执行。这通常是通过递归方式实现的。
- 执行阶段(Computation Phase):执行每个小任务,并生成结果。
- 结果合并阶段(Join Phase):合并小任务的结果,生成大任务的结果。这也通常通过递归的方式实现,与拆分阶段对应。
- 善后阶段(Finalize Phase):所有任务的结果都已合并完毕,大任务的结果也已经生成,可以进行善后工作,比如释放资源等。
每个阶段都有一定开销,从整个执行流程上看,执行阶段占的时间越长,性能提升就越高。在数据量较少,或者执行操作开销较大时,并行处理不但不能提高性能,还会由于线程管理和任务分配的开销而导致性能下降。
再次回到上面这个案例:
// 将 Code 转换为对应的枚举
public static OrderStatus parallelParseByCode(int code) {
return Stream.of(values())
.parallel()
.filter(status -> status.getCode() == code)
.findFirst()
.orElse(null);
}
首先,枚举的数量非常小,其次,执行逻辑非常简单,仅进行一个等值比较。在这种情况下使用 parallel 函数,将致使线程管理和任务分配开销巨大,从而成为系统瓶颈。
二、解决方案
既然问题是通过 parallel 函数引入的,那解决方案便是:删除 parallel 函数调用,直接串行执行即可。
修改后的代码如下:
public static OrderStatus parseByCode(int code) {
return Stream.of(values())
// .parallel() 直接使用串行执行
.filter(status -> status.getCode() == code)
.findFirst()
.orElse(null);
}
使用相同的数据重新测试,耗时如下图所示:
图片
可见,性能直接提升 10 倍不止。
三、示例&源码
代码仓库:https://gitee.com/litao851025/learnFromBug
代码地址:https://gitee.com/litao851025/learnFromBug/tree/master/src/main/java/com/geekhalo/demo/thread/parallelfun