遇到 Java 8 Stream 处理大集合内存溢出，最稳妥的方向是避免一次性加载全量数据到内存，改为分页或游标流式处理，而不是单纯依赖增加堆内存。

核心原因与误区

Java 8 的 Stream 中间操作支持懒加载，但数据源加载方式决定内存占用。如果在使用 Stream 之前已经通过 listAll() 这样的方法将数据库全表数据加载到了 List 中，那么 list.stream() 只是对内存中已有数据的遍历，无法节省内存。

像 sorted 和 distinct 这样的有状态操作必须缓冲部分或全部数据才能完成计算，当数据量超过堆内存限制时就会触发 OOM。公开资料中没有可靠的量化数据说明 Stream 比传统循环具体节省或消耗多少内存，这取决于具体操作链的组合，但有状态操作必然带来额外缓冲是确定的机制。

代码层优化方案

第一步，检查数据加载方式。确认是否在 Stream 之前已经构建了大型集合。如果是数据库查询，改为分页查询或使用 Scroll 游标。

方案一：MyBatis 游标流式处理

使用 MyBatis 的 Cursor 配合 ResultSetType.FORWARD_ONLY，避免一次性加载所有结果集。

<!-- Mapper XML -->
<select id="selectUserCursor" resultMap="UserResult" resultSetType="FORWARD_ONLY" fetchSize="1000">
    SELECT * FROM users WHERE status = 1
</select>

<!-- Java 接口 -->
Cursor<User> selectUserCursor();

<!-- 业务调用 -->
try (Cursor<User> cursor = userMapper.selectUserCursor()) {
    StreamSupport.stream(
        Spliterators.spliteratorUnknownSize(cursor.iterator(), Spliterator.ORDERED),
        false
    ).forEach(user -> {
        // 处理单条数据，处理完即释放
        process(user);
    });
}

方案二：分页查询封装

如果必须使用 List，请手动控制分页大小，避免单次查询过大。

int pageNum = 0;
int pageSize = 1000;
while (true) {
    List<User> page = userMapper.selectPage(pageNum, pageSize);
    if (page == null || page.isEmpty()) {
        break;
    }
    page.stream().forEach(this::process);
    pageNum++;
    // 手动触发 GC 或等待，避免累积过快
}

第二步，审查 Stream 操作链。移除不必要的 sorted 或 distinct。如果必须去重，考虑在数据库层面完成。

第三步，谨慎使用并行流。parallelStream 会使用 ForkJoinPool，可能会创建多个缓冲区，反而增加内存压力。在内存敏感场景下，优先使用顺序流。

JVM 参数与临时止血

如果没有办法立即重构代码，可以先尝试调整 JVM 堆内存参数作为临时止血措施，但这不是长久之计。生产环境建议 Xms 与 Xmx 设置一致以避免动态调整开销。

启动参数调整示例：

-Xms4g -Xmx4g

注意：具体数值应根据服务器物理内存设定，通常不超过物理内存的 70%。

验证与监控命令

1. 开启 GC 日志

在 Java 8 环境下，添加以下参数开启详细 GC 日志：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

观察 Full GC 频率。如果优化有效，Full GC 的频率应该显著降低，且老年代占用增长变缓。

2. 堆内存监控

使用 jmap 查看堆直方图，确认大对象实例数量是否减少：

jmap -histo:live <pid> | head -n 20

或使用 VisualVM 连接远程进程，查看 Heap Dump 分析 dominating objects。

3. 压测验证

在测试环境模拟同等数据量进行压测，观察应用是否还能稳定运行而不抛出 OutOfMemoryError。

常见坑

不要迷信 parallelStream 能解决性能问题，它在内存受限环境下往往是副作用更大的选项。

避免在 Stream 链中执行副作用操作，比如直接修改外部集合，这可能导致不可预知的并发问题或数据不一致。

如果使用了自定义的 Spliterator 或 Iterator，确保正确处理结束状态，避免无限循环导致内存持续分配。

处理 IO 资源时，如果 Stream 源是文件 IO，确保使用 try-with-resources 正确关闭，避免句柄泄漏间接导致问题。