性能优化是技术人的永恒话题，当我们遇到性能问题时，你的第一反应是什么？
数据库索引优化，缓存优化，算法优化？
但，有时性能杀手往往就是性能优化引入的。
今天一大早，小艾刚到公司便收到一组系统报警，原来有一个接口报了一堆的慢情况。仔细排查，发现是前两天为服务域提供的一个订单的查询接口，该接口刚上线不久，正处于放量阶段，小艾立即惊出一身冷汗，不会是数据库出现了 慢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);}逻辑简单到令人发指，只有两步：
小艾，仔细观察这个接口，发现一个现象：当入参较多时，接口的性能变的非常差。
这个也比较好理解，系统使用的是 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 的转换居然耗时这么多，真是太不可思议！
很明显是转化这步出了问题，其核心代码如下所示：
// 使用 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 的 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 函数，将致使线程管理和任务分配开销巨大，从而成为系统瓶颈。
既然问题是通过 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
本文链接：http://www.28at.com/showinfo-26-60900-0.html我被 parallel 函数雷了
声明：本网页内容旨在传播知识，不代表本站观点，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。