迭代器模式案例

wen java案例 2026-08-09 3

《迭代器模式实战案例：从集合遍历到大数据流式处理的架构进化》**

迭代器模式案例

目录导读

迭代器模式：一个被低估的“隐形架构师”
经典案例重构：电商订单系统的“分页暗战”
进阶案例：从内存遍历到数据库游标（Cursor）的飞跃
高并发场景：迭代器模式如何解决“用户画像实时计算”性能瓶颈
反模式警示：何时不该用迭代器？
常见问题解答（FAQ）
模式融合与未来演进

迭代器模式：一个被低估的“隐形架构师”
在GoF的23种设计模式中，迭代器（Iterator）常被视为“玩具级”模式，当你在阅读本文案例时会发现，它实则是从List<String>到Kafka Stream的底层通用协议，其核心价值在于：将集合的“存储结构”与“遍历算法”解耦，以Java为例，ArrayList与HashSet的迭代器实现完全不同，但客户端代码只需面向Iterator接口编程,即可无视底层差异。

经典案例重构：电商订单系统的“分页暗战”
场景描述：某电商后台需要导出30天内全量订单（约500万条），初版代码使用for循环＋get(i)直接访问数据库ResultSet，导致两个问题：

内存溢出（一次性加载全部订单对象）
外键关联查询导致N+1次SQL

迭代器模式解法：

class OrderIterator implements Iterator<Order> {
    private int page = 0;
    private List<Order> currentPage;
    private int cursor = 0;
    @Override
    public boolean hasNext() {
        if (cursor < currentPage.size()) return true;
        // 主动分页拉取，每次1000条
        currentPage = orderMapper.queryByPage(page++, 1000);
        cursor = 0;
        return !currentPage.isEmpty();
    }
    // next() 直接返回当前游标对象
}

效果：内存占用恒定在1000个对象以内，且由迭代器内部封装分页逻辑，业务代码只用while(iter.hasNext()){...}，此案例完美匹配迭代器模式案例的教科书定义：代替foreach循环，隐藏真实容器（此处为数据库分页结果集）。

进阶案例：从内存遍历到数据库游标（Cursor）的飞跃
在Spring Data JPA中，Stream<T> streamAll()的实现原理即一个惰性迭代器，它仅在next()调用时才向数据库发送SQL。
对比数据：

传统findAll()：执行1次大查询，换取500万行实体，JVM GC耗时4.2秒
streamAll()迭代器：执行5000次小查询（每次1000行），但GC耗时降到0.3秒，且延迟降低47%

这里的关键是迭代器模式允许“按需计算”，将集合的“存在”与“获取”彻底分离，这正是流式处理（如Apache Flink）的前置思想。

高并发场景：迭代器模式如何解决“用户画像实时计算”性能瓶颈
案例：某广告推荐系统需要每5分钟扫描全量活跃用户ID（约2000万），并计算特征，最初基于Redis SCAN命令的非阻塞迭代器实现：

Iterator<String> userIterator = redis.scan(ScanOptions.match("user:*").count(1000));
while(userIterator.hasNext()){
    String id = userIterator.next();
    computeAsync(id); // 异步处理，不阻塞迭代
}

优势：

避免了一次性KEYS *命令导致Redis阻塞
迭代器内部自动处理游标续传（Cursor），即使中途网络异常，也能从断点继续，而传统for遍历无法做到。

反模式警示：何时不该用迭代器？

当集合本身是稀疏矩阵（如90%元素为空）时，直接迭代会浪费大量无用判断，此时应使用SparseIterator装饰器进行过滤。
当集合需要频繁增删且遍历时，迭代器会抛出ConcurrentModificationException，应改为CopyOnWriteArrayList或WeaklyConsistentIterator（如ConcurrentHashMap的迭代器）。

常见问题解答（FAQ）

Q1：迭代器模式与Stream API（Java 8）有何区别？
A：Stream API是迭代器的高级封装，增加了函数式操作（map/filter/reduce），但迭代器模式更底层——它允许你控制“如何取得下一个元素”，而Stream默认是顺序拉取，在异步场景（如异步数据库驱动），自定义迭代器可轻松实现CompletableFuture的背压控制。

Q2：如何让自定义迭代器支持remove()操作？
A：需谨慎，若底层容器是ArrayList，remove()后需修改cursor索引，一个健壮做法是：记录lastReturned指针，并在remove()时检查是否已被并发修改（modCount对比）。

Q3：大规模数据下，迭代器会不会导致“连接泄漏”？
A：可能的，若迭代器持有数据库ResultSet但未关闭，连接池会被耗尽，解决：实现AutoCloseable，在close()中释放底层Statement，实际项目中，推荐使用Spring的JdbcTemplate + RowCallbackHandler（内部即迭代器回调）。

模式融合与未来演进
迭代器模式并非孤立存在，它在现代架构中与工厂模式（创建迭代器）、策略模式（定义不同遍历规则）结合紧密，在Redis、Cassandra、Kafka等分布式存储中，游标本质就是跨网络的分页迭代器，未来的AI推理引擎（如TensorFlow Data API）也采用迭代器懒加载内存Tensor。

建议编码原则：对外永远暴露Iterator<T>接口而非List<T>，你的代码将自动获得“懒加载+流式处理+无界数据集”的扩展能力——这就是迭代器模式案例带给我们的架构哲学。

（全文完）