iterator遍历本身不导致内存溢出，真正风险在于源头一次性加载巨型集合；需坚持惰性加载、分批处理、避免全量收集、限流控制及防止隐性引用。
用 Iterator 遍历巨型集合本身不会直接导致内存溢出，真正危险的是“把整个巨型集合先加载进内存”，再用 Iterator 去遍历。Iterator 只是提供一种安全、统一的遍历接口，它不解决数据源头的内存压力问题。关键在**源头控制 + 惰性消费 + 分批处理**。
源头必须惰性加载，不能一次性全读
如果集合本身是内存中已存在的 ArrayList 或 LinkedList（含上亿元素），那内存早已爆了，Iterator 再怎么遍历也于事无补。真正可行的是让数据源本身支持按需拉取：
- 数据库查询用 分页游标（如 JDBC 的 setFetchSize + ResultSet.next），而不是 select * 加载全部到 List
- 文件读取用 Files.lines(path).iterator() 或 BufferedReader.lines().iterator()，每调用一次 next() 才读一行，不缓存全文
- 网络流或日志管道用自定义 Iterator，内部封装 InputStream/Channel，每次 next() 解析一个数据块
避免在迭代过程中触发全量操作
即使用了 Iterator，若后续代码把它转成大集合，就前功尽弃：
- ❌ 错误：iterator.forEachRemaining(list::add) —— 把所有元素又塞回新 List
- ❌ 错误：StreamSupport.stream(Spliterators.spliteratorUnknownSize(iterator, 0), false).collect(Collectors.toList())
- ✅ 正确：用 forEachRemaining 处理单个元素，或配合 Stream.limit(n) 控制总处理条数
- ✅ 正确：对每一批（如 1000 条）做聚合后立即丢弃引用，不累积
结合 limit 和分段消费控制峰值
面对不确定长度但可能超大的流式数据，光靠 hasNext()/next() 不够，需主动限流：
- 用 AtomicInteger counter 在循环内计数，达到阈值就 break，防止无限处理
- 对超长日志或消息队列，可包装为 “带批次的 Iterator”：每次 nextBatch() 返回最多 N 个元素的子迭代器，处理完即释放
- 搭配 Stream API 时，优先用 takeWhile（条件满足即停）而非 limit（强制取满），更早终止无效拉取
警惕静态引用和闭包捕获导致的隐性持有
Iterator 本身轻量，但遍历逻辑中若持有外部大对象，会阻碍 GC：
- 避免在 lambda 或匿名内部类中引用整个巨型集合、大缓存 Map 或未关闭的资源
- 检查自定义 Iterator 实现，确认其内部字段（如 buffer、stream、cursor）在遍历结束后能被及时置 null 或 close
- 特别注意 Spring 管理的 Bean 中维护的 Iterator 或缓存状态，生命周期过长易堆积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
