理解 Java 的 Iterable 长度概念
在 Java 中，Iterable
如果一个实现同时继承自 Collection，那么可以通过 size() 获得元素个数，通常复杂度为 O(1)；但对于纯 Iterable，size() 是不可用的。这个区分直接决定了长度的获取方式，也是后续讨论的前提。务必牢记：Iterable 不等同于有固定长度的集合。
在设计 API 或编写工具方法时，理解这一点尤为重要：若只有 Iterable，你需要通过迭代来计算长度；若已经是 Collection，则可以直接使用其长度信息。这两者在实现和性能上有本质区别。
Iterable 与集合的边界
当底层实现不是 Collection 时，想要得到长度，通常需要对 iterator() 进行完整遍历，统计元素数量。这意味着长度计算通常是一个 O(n) 的过程，并且在某些实现中会带来副作用或耗尽数据的风险。在设计时要考虑可重复性和数据源的性质，避免误把一次性数据流当成可重复的集合。下面的例子将帮助你快速理解。
常见误区全解析
在实际开发中，关于 Java 的 Iterable 长度计算，存在若干常见误解。理解这些误区有助于避免性能陷阱和错误的 API 选择。本文将逐条拆解，并给出正确的处理思路。
误区一：Iterable 总是有已知的长度。很多人认为每个 Iterable 都能给出长度信息，但现实中很多实现是惰性生成或单次遍历的，长度在创建时并不可知。这导致直接使用长度信息的代码在某些场景下会失效。下面的示例能帮助你辨识这一点。请注意区分实现类型。
// 例子：一个简单的 Iterable，没有固定长度的信息
Iterable<Integer> it = () -> new Iterator<Integer>() {int i = 0;public boolean hasNext() { return i < 3; }public Integer next() { return i++; }
};
从这段简化的示例可以看出，长度在创建时并不可知，必须通过遍历来统计。因此，直接依赖长度是不可取的。
误区二：对 Iterable 使用 size() 获取长度。
Iterable 不提供 size()，只有实现了 Collection 的对象才有 size()。如果你尝试对一个 Iterable 调用 size()，编译器会提示找不到符号，运行时也会遇到方法不存在的异常。下面的代码段说明了这一点。避免在泛型方法签名中把 Iterable 错误地当成 Collection。
Iterable<String> it = java.util.Arrays.asList("a","b"); // 实际上是一个 List，实现了 Collection
int s = it.size(); // 编译通过，但只有当 it 的静态类型是 Collection 时才可行
更常见的错误是将 size() 用在仅实现了 Iterable 的数据源上，结果编译报错或运行时崩溃。正确的前提是先判断或约束类型是否实现了 Collection，否则需要其他手段来统计长度。
正确做法与实现策略
在大多数场景中，处理 Iterable 的长度时应遵循以下策略：若底层是 Collection，直接获取长度；否则通过遍历来统计，并清楚可重复性与性能的取舍。下面按场景给出具体做法和代码示例，帮助你在实际工作中快速落地。
除了计数，还可以在统计的同时进行其他处理，或将数据缓存以便重复遍历。选择哪种策略，取决于数据源的可重复性和对性能的要求。以下示例覆盖了常见的实现方式。
场景一：需要计数但底层是 Iterable
计数的基本做法是遍历并统计元素个数。这是一个 O(n) 的过程，且在某些实现中会消耗数据源，因此在需要重复遍历时应考虑缓存或转存为 List。示例代码如下。
public static int countIterable(Iterable<T> it) {int count = 0;for (T item : it) {count++;}return count;
} 如果你希望在统计的同时对每个元素执行其他操作，可以结合 forEach 语义来实现，避免重复遍历。但要明确一次性读取的性质，避免造成重复访问的隐患。
另一种做法是把 Iterable 转换为一个 Stream，然后使用 count() 来获得长度。这在某些场景下更简洁，但同样会消费数据源，因此需要在转换前确认是否可重复访问。下面是使用 Stream 的示例。
import java.util.stream.StreamSupport;public static long countWithStream(Iterable<T> it) {return StreamSupport.stream(it.spliterator(), false).count();
} 场景二：底层是 Collection，直接获取长度
如果你明确拥有一个实现了 Collection 的对象，直接调用 size() 是最简单、最高效的方式，复杂度通常为 O(1)。这也是性能最优的路径，但在并发场景下，请关注集合的同步性和可见性。示例代码如下。
import java.util.List;
import java.util.Arrays;List<String> list = Arrays.asList("x","y","z");
int len = list.size(); // 3
需要注意的是，若你在迭代过程中对集合进行了结构修改，size() 的返回值可能与实际元素数量不同，因此在并发环境下要谨慎使用。另外，若你的类型只是单纯的 Iterable，这条路径并不可用，需要回到场景一的处理方式。
场景三：需要保持迭代顺序与可重复性
对于需要多次遍历的场景，直接对原始 Iterable 进行多次遍历会导致数据源被多次消费，或是在惰性生成时产生副作用。因此，最佳实践是将数据先缓存到一个可重复访问的容器中，例如 List，再进行多次遍历。这适用于难以预测的惰性数据源。示例代码如下。
import java.util.ArrayList;
import java.util.List;public static List<T> materialize(Iterable<T> it) {List<T> list = new ArrayList<>();for (T item : it) {list.add(item);}return list;
} 将 Iterable 先转换为 List 之后，你就获得了可重复的遍历能力以及对长度的精确控制。注意缓存的内存成本，在大数据量场景下要评估是否可接受。
