最简单有效的预防无限流手段是在创建后、耗时操作前加limit()；它必须位于flatMap等高危操作之前，否则内部流已无限展开；可用takeWhile实现条件截断，配合分批处理控内存，警惕源头隐式无限行为。
直接在无限流创建后、进入耗时操作前加 limit()，是最简单有效的预防手段。关键不是“用了 limit”，而是它必须出现在所有可能触发无限展开的中间操作之前，否则仍会卡在内部流生成阶段。
limit 必须放在 flatMap 之前
flatMap 是高危操作，它会把每个元素映射成一个新流。如果外层是无限流（如 iterate 或 generate），又没提前限制元素个数，flatMap 就可能为无穷多个元素各自启动一个子流——哪怕你后面写了 limit，也拦不住内部流已开始无限构造。
- ❌ 错误写法：Stream.iterate(1, i -> i + 1).flatMap(i -> Stream.generate(() -> "item-" + i)).limit(100)
- ✅ 正确写法：Stream.iterate(1, i -> i + 1).limit(100).flatMap(i -> Stream.of("item-" + i))
用 takeWhile 替代 limit 实现条件截断
当终止条件依赖元素值而非固定数量时，takeWhile 更安全。比如按递推规则生成直到某个阈值，比硬写 limit(1000) 更贴近业务逻辑，也避免因预估不准导致截断过早或溢出。
- Stream.iterate(1, i -> i + 1).takeWhile(i -> i "item-" + i)
- 相比 limit(1000)，takeWhile 在遇到第一个不满足条件的元素时立即停止，不会多拉取
组合 limit 与小批量处理控制内存峰值
即使加了 limit，若单次处理的数据量依然很大（如 limit(10_000_000)），后续 collect 或 sorted 仍可能爆堆。应配合分批策略：
- 先用 limit 控制总规模（如最多处理 100 万条）
- 再用 skip/limit 分段处理，每批几千到几万条，处理完即释放引用
- 避免 sorted、collect(Collectors.toList()) 等全量入内存操作；改用 forEach 或自定义 Spliterator 流式消费
警惕“假有限”流：检查源头是否真可控
有些流看似被 limit 了，但源头本身存在隐式无限行为。例如：
- Files.lines(path).filter(...).limit(N) —— 安全，因为 lines 是惰性读取
- Stream.generate(() -> heavyObject()).limit(N) —— 危险，heavyObject() 每次都新建大对象，N 很大时仍会 OOM
- 正确做法：把对象构造移到 map 内，或复用对象池，或改用 iterate + 状态控制
