Java Stream API无限流需谨慎约束：必须在flatMap前limit以防内存溢出；用takeWhile替代limit实现语义化截断；分批处理避免collect全量入内存；警惕Stream.generate等源头隐式无限行为。
Java Stream API 本身不存储数据，但无限流（如 Stream.iterate 或 Stream.generate）若未合理约束，极易因终端操作不当引发内存溢出（OutOfMemoryError）或死循环。关键不在“是否用了 limit”，而在于**何时限、怎么限、限在哪一环**。
必须在 flatMap 前加 limit
flatMap 是高危操作，它会为每个上游元素生成一个新流。如果上游是无限流且没提前截断，哪怕后续写了 limit(100)，JVM 已开始构造无穷多个子流，内存会瞬间飙升。
- ❌ 错误：先
flatMap再limit—— 内部流已无限展开Stream.iterate(1, i -> i + 1).flatMap(i -> Stream.generate(() -> "item-" + i)).limit(100) - ✅ 正确：先
limit控制上游数量，再flatMapStream.iterate(1, i -> i + 1).limit(100).flatMap(i -> Stream.of("item-" + i))
用 takeWhile 替代 limit 实现语义化截断
当终止条件依赖元素值（比如“生成到第一个大于 1000 的数为止”），硬写 limit(1000) 不仅不安全，还可能截早或截晚。用 takeWhile 更贴近业务逻辑，且真正满足条件即停，不会多拉取一个元素。
- 示例：
Stream.iterate(1, i -> i + 1).takeWhile(i -> i <= 1000).map(i -> "val-" + i) - 对比
limit(1000)，它不依赖预估数量，避免因规则变化导致溢出
分批处理 + 流式消费，避开全量入内存
即使加了 limit(1_000_000)，后续若接 collect(Collectors.toList()) 或 sorted()，仍会一次性加载全部元素到堆中。应改用低内存压力的方式：
立即学习“Java免费学习笔记（深入）”；
- 用
forEach或自定义Spliterator边流边处理，不缓存 - 对大数据集，先
limit总规模，再配合skip/limit分段处理，每批几千条，处理完立即释放引用 - 避免
count()、无标识的reduce()、collect()等非短路终端操作
警惕源头隐式无限行为
有些流看似被 limit 了，实则源头已失控：
- ✅ 安全：
Files.lines(path).filter(...).limit(N)——lines()是惰性读取，按需加载行 - ❌ 危险：
Stream.generate(() -> new HeavyObject()).limit(N)—— 每次调用HeavyObject()都新建大对象，N 很大时 GC 压力剧增 - 建议：优先用原始类型流（如
IntStream），减少装箱和 GC 开销
