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