Java List分批处理：Stream流与Guava实战技巧

Java中List分批处理看似简单，实则暗藏性能陷阱与并发风险：原生subList轻量但返回视图、修改会波及原集合；Guava的Lists.partition虽简洁一行搞定，却同样基于视图、不支持增删且对空值和非法size零容忍；Stream流若强行用collect硬凑分批，不仅逻辑臃肿、易出错，更在并行场景下彻底失效——真正可靠的做法是根据实际需求抉择：需独立副本且允许后续修改时自定义Collector，追求极致简洁且原List稳定不变时优选Guava，而高频小批量、低开销场景下subList仍是首选；一切技术选型的前提，是先厘清“分完之后要不要改、原List会不会变、并发谁来同步”这三个本质问题。

Java原生List分批：别直接用Stream.collect()硬凑

Stream API本身不提供“按大小切分List”的终端操作，collect()只能归约到单个结果，强行用Collectors.groupingBy()配合索引计数既难读又易错——尤其在并行流下索引会乱序。真正靠谱的起点是把List转成可索引访问的结构，再按步长截取。

• 用list.subList(fromIndex, toIndex)最轻量，但要注意它返回的是原List的视图，修改会影响原集合；如需独立副本，得套一层new ArrayList(...)
• 避免在循环里反复调用stream().skip().limit()，每次都会遍历前N项，时间复杂度O(n²)，10万元素就明显卡顿
• 如果原始List是LinkedList，subList()性能尚可；但如果是ArrayList，随机访问快，subList()也快——别被“链表适合分页”这种过时经验带偏

Guava的Lists.partition()：简单场景首选，但注意返回值语义

Lists.partition(list, size)确实一行解决分批，但它返回的是List>，且每个子List仍是原List的subList视图。这意味着：

• 如果后续要对某个分片做add()或remove()，会抛UnsupportedOperationException——因为subList默认不支持结构性修改
• 若原始List后续被修改（比如clear()），所有partition出来的子List会同步失效，读取时可能抛ConcurrentModificationException
• size ≤ 0会直接抛IllegalArgumentException，生产代码里必须提前校验，不能依赖Guava兜底

Stream分批归约：用Collectors.collectingAndThen + 自定义Collector

真要用Stream做分批归约，核心是控制“累积器状态”，而不是靠map/filter拼凑。推荐封装一个复用的Collector，例如：

Collector<T, ?, List<List<T>>> partitioning(int size) {
    return Collector.of(
        () -> new ArrayList<List<T>>(),
        (acc, item) -> {
            if (acc.isEmpty() || acc.get(acc.size()-1).size() == size) {
                acc.add(new ArrayList<>());
            }
            acc.get(acc.size()-1).add(item);
        },
        (a, b) -> { throw new UnsupportedOperationException(); }, // 不合并
        collectingAndThen(identity(), x -> x)
    );
}

关键点：

• 第三个参数（combiner）必须抛异常或明确注释“不支持并行”，因为分批逻辑天然有顺序依赖
• 别用Collectors.toMap()模拟分组，key算索引再取模，流式处理中无法保证元素到达顺序，结果不可靠
• 这个Collector返回的是全新List实例，和原List完全解耦，适合需要后续修改分片内容的场景

边界情况和性能提醒：size为0、null、超大分片

实际写业务时，size参数往往来自配置或用户输入，最容易漏掉这些检查：

• size == 0：Guava直接炸；原生subList(0, 0)虽合法，但循环里容易陷入死循环（步长为0）
• list == null：Guava和自定义Collector都不会自动判空，NPE风险高，建议前置Objects.requireNonNull(list)
• size > list.size()：Guava返回单元素List，符合直觉；但自己写循环时若没处理好边界，可能漏掉最后一段
• 分片数上万时，Guava的partition内存占用略低（共享底层数组）；而Stream Collector每段都new ArrayList，GC压力稍大——但差不了几个MB，别过早优化

分批这事，核心从来不是“怎么写出来”，而是想清楚：分完之后要不要改、原List会不会变、并发环境下谁负责同步。这几个问题没答案，代码写得再短也没用。

理论要掌握，实操不能落！以上关于《Java List分批处理：Stream流与Guava实战技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！