我被 Parallel 函数雷了

开发 前端
系统使用的是 in 语句对数据进行查询,示例:select * from order_info where user_id in (?),当入参数据量非常大时,sql 执行耗时变高。这可能是一个原因,但MySQL 慢请求中未记录任何信息,说明 sql 的执行时间没有超过 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);
}

逻辑简单到令人发指,只有两步:

  1. 根据传入的 user id 从数据库中查询订单
  2. 将查询的 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);
}

看完核心代码,请思考几分钟,问题可能出现在哪里?

  1. Stream 操作?Stream 比 for 循环性能超差些,但还不至于有这么大差异
  2. 反射、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 的整体执行流程:

图片图片

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

  1. 分割阶段(Fork Phase):将大任务拆分成若干个小任务,直到任务的规模足够小,可以直接执行。这通常是通过递归方式实现的。
  2. 执行阶段(Computation Phase):执行每个小任务,并生成结果。
  3. 结果合并阶段(Join Phase):合并小任务的结果,生成大任务的结果。这也通常通过递归的方式实现,与拆分阶段对应。
  4. 善后阶段(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

责任编辑:武晓燕 来源: geekhalo
相关推荐

2013-06-20 11:11:00

程序员经理

2020-12-18 08:28:13

Redis数据数据库

2021-06-29 10:02:04

亚马逊机器解雇

2013-04-25 13:44:53

挨踢人物传

2011-08-31 11:00:27

MIUI小米手机雷军

2021-05-10 07:30:33

Google技术谷歌

2021-01-18 11:27:03

Istio架构云环境

2020-04-07 08:00:02

Redis缓存数据

2021-09-13 08:41:52

职场互联网自闭

2022-05-11 09:18:04

微软PowerShell降级

2023-10-31 08:01:48

Mybatis参数jdbcurl​

2010-08-30 11:12:42

2020-03-12 07:55:50

访问量飙升DDoS

2010-11-18 16:29:54

2014-11-05 09:27:56

陈彤雷军

2023-09-28 13:21:32

2019-12-09 09:12:59

程序员年薪裁员

2013-12-18 16:20:20

雷军小米

2020-02-12 08:09:32

日志规范推广

2024-06-18 08:31:33

点赞
收藏

51CTO技术栈公众号