stream.iterate生成无穷序列时程序卡死或oom，因其默认无终止条件，调用collect()、count()等非短路操作会无限生成元素；必须配合limit()、takewhile()（java 9+）或findfirst()使用，且seed与unaryoperator需类型一致、纯函数、避免对象复用。
Stream.iterate 生成无穷序列时为什么程序卡死或 OOM？
因为 Stream.iterate 默认不带终止条件，返回的是真正「惰性求值但无限」的流——一旦你调用 collect()、count() 或没加 limit() 就遍历，JVM 就会一直生成元素直到内存耗尽或栈溢出。
- 常见错误现象：
OutOfMemoryError: Java heap space或线程长时间无响应 - 必须搭配
limit(n)、takeWhile()（Java 9+）或findFirst()等短路操作使用 - Java 8 不支持
takeWhile()，别试图用filter().findFirst()替代——它不会提前终止迭代，仍会无限生成 - 示例：生成前 5 个斐波那契数 ——
Stream.iterate(new long[]{0,1}, t -> new long[]{t[1], t[0]+t[1]}).limit(5).mapToLong(t -> t[0])
iterate 的 seed 和 unaryOperator 参数怎么写才不出错？
seed 是起点值（不是初始状态容器），unaryOperator 必须是纯函数：输入一个值，输出下一个值，且不能修改入参对象（尤其用数组或可变对象时）。
- 错误写法：
Stream.iterate(new int[]{1}, arr -> { arr[0]++; return arr; })—— 复用同一数组引用，后续limit(3)会得到[3],[3],[3] - 正确写法：每次新建对象，如
Stream.iterate(1, n -> n + 1)或Stream.iterate(new int[]{1}, arr -> new int[]{arr[0] + 1}) - 注意类型一致性：seed 类型必须和 unaryOperator 输入/输出类型完全匹配，否则编译失败（泛型擦除后无法隐式转换）
- 性能影响：频繁新建小对象（如包装类、短数组）会增加 GC 压力，简单场景优先用基本类型或预分配缓存
Java 9+ 的 iterate 重载版本有什么实际好处？
Java 9 新增了 Stream.iterate(T seed, Predicate super T> hasNext, UnaryOperator<t> next)</t>，把「是否继续」逻辑从外部移到内部，避免漏写 limit 导致的无限循环。
- 典型场景：生成不超过 100 的偶数 ——
Stream.iterate(0, n -> n n + 2)，比iterate(0, n -> n + 2).takeWhile(n -> n 更早截断（next 不会在 102 被调用） - 兼容性风险：Java 8 项目不能用，升级前确认 JDK 版本
- 注意：hasNext 在 seed 上也会执行一次，所以
iterate(100, n -> n 至少产出一个元素 - 错误现象：如果 hasNext 逻辑有副作用（比如修改外部变量），可能因流的惰性与并行特性导致行为不可预测
iterate 和 generate 哪个更适合做无穷序列？
Stream.generate 适合无状态、独立生成（如随机数、UUID），iterate 专为「当前值 → 下一个值」的状态传递设计；混用会导致语义混乱或 bug。
立即学习“Java免费学习笔记（深入）”；
- 别用
generate模拟递推：比如想生成等差数列却写generate(() -> { x += 2; return x; })—— 并行流下结果不可控，且违反无状态原则 - 别用
iterate做无依赖生成：比如iterate(0, n -> ThreadLocalRandom.current().nextInt())是低效且误导的，应直接用generate(ThreadLocalRandom.current()::nextInt) - 性能差异不大，但可读性差的写法会让协作者误判数据依赖关系，后期排查边界条件（如越界、初值异常）更困难
