我被 Parallel 函数雷了_数据库技术

1. 问题&分析

性能优化是技术人的永恒话题，当我们遇到性能问题时，你的第一反应是什么？

数据库索引优化，缓存优化，算法优化？

但，有时性能杀手往往就是性能优化引入的。

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);
}

选了几个订单较多的用户进行测试，打印日志如下：

我被 Parallel 函数雷了图片

好奇怪，数据库操作耗时有限，但 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 的整体执行流程：

我被 Parallel 函数雷了图片

其执行主要分为以下几个阶段：

分割阶段（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 函数，将致使线程管理和任务分配开销巨大，从而成为系统瓶颈。

2. 解决方案

既然问题是通过 parallel 函数引入的，那解决方案便是：删除 parallel 函数调用，直接串行执行即可。

修改后的代码如下：

public static OrderStatus parseByCode(int code) {
    return Stream.of(values())
            // .parallel() 直接使用串行执行
            .filter(status -> status.getCode() == code)
            .findFirst()
            .orElse(null);
}

使用相同的数据重新测试，耗时如下图所示：

我被 Parallel 函数雷了图片