让AI帮我写Java Stream：差点把线上内存搞崩了

作者：袖梨 2026-06-13

上周订单导出功能重构，我想着用AI提速，就把需求丢给了Cursor——把原来for循环拼接的逻辑改成Stream并行处理。AI写得很快，三分钟就给我吐了一段看起来很优雅的parallelStream代码，我还觉得挺满意，review了一遍就合了。

上线第二天，凌晨告警就来了。订单服务堆内存飙到95%，GC根本回收不掉。翻日志一看，全是"Java heap space"，导出接口超时率从0.3%直接干到了12%。

问题出在哪

AI给我的代码大概长这样：

List<OrderExportDTO> result = orders.parallelStream()
    .map(order -> enrichOrderDetail(order))  // 每个订单查3次远程接口
    .map(dto -> calculatePrice(dto))          // 价格计算，涉及BigDecimal运算
    .collect(Collectors.toList());

看起来没毛病对吧？但这里藏了两个坑。

第一个坑是parallelStream的默认线程池。AI压根没提这茬——parallelStream用的是ForkJoinPool.commonPool()，这个池子的大小等于CPU核心数-1。我那台8核的机器，只有7个工作线程，而导出请求一秒能来二三十个。七个人干活，二三十个任务排队，全堆在内存里等着。

第二个坑更隐蔽。enrichOrderDetail方法里调了三个远程接口，每个接口平均耗时200ms。parallelStream的工作线程被远程调用阻塞在那，ForkJoinPool的任务队列疯狂堆积。原来for循环虽然慢，但至少是逐条处理，不会把几万条数据同时展开到内存里。改了Stream之后，反而是"快"出了问题——所有数据同时进入处理流水线，内存占用直接翻了十几倍。

我是怎么排查的

说实话，第一反应是怀疑远程接口变慢了。翻了一轮监控，接口RT没变化。然后我jmap了一把，看到内存里全是CompletableFuture和ForkJoinTask对象，才反应过来是并行流搞的鬼。

jstack看线程状态更直观——7个ForkJoinPool工作线程全部停在WAITING状态，等远程调用返回。而主线程在LinkedBlockingQueue.take()上阻塞，等着collect完成。

// jstack关键信息
"ForkJoinPool.commonPool-worker-3" - WAITING on java.util.concurrent.CompletableFuture
"ForkJoinPool.commonPool-worker-5" - WAITING on java.util.concurrent.CompletableFuture
"http-nio-8080-exec-12" - WAITING on java.util.concurrent.LinkedBlockingQueue.take()

修复方案

不要在parallelStream里做IO密集型操作，这应该是个常识，但AI不会主动告诉你。它只负责把代码写出来，不管你的业务场景适不适合。

我改回for循环了？没有。换了个思路——用自定义线程池 + CompletableFuture组合，把并行度和IO隔离开：

ExecutorService exportPool = new ThreadPoolExecutor(
    4, 4, 60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),  // 限制队列长度，别让任务堆积
    new ThreadPoolExecutor.CallerRunsPolicy()  // 队列满了主线程自己跑
);List<CompletableFuture<OrderExportDTO>> futures = orders.stream()
    .map(order -> CompletableFuture.supplyAsync(
        () -> enrichOrderDetail(order), exportPool
    ))
    .collect(Collectors.toList());List<OrderExportDTO> result = futures.stream()
    .map(CompletableFuture::join)
    .collect(Collectors.toList());