Java集合元素数量计算方法

Java集合元素个数看似简单，实则暗藏多重陷阱：所有标准集合统一用O(1)时间复杂度的`size()`方法获取元素个数，但需警惕null调用引发的空指针异常、并发集合（如ConcurrentHashMap）中`size()`返回的可能是不精确的近似值、Stream流根本没有`size()`而必须用会触发终端操作且返回long的`count()`；更易被忽视的是，开发者常混淆数组的`length`字段、字符串的`length()`方法与集合的`size()`，三者语义和语法截然不同，混用将导致编译失败。从单线程到高并发、从集合直用到函数式流处理，`size()`背后牵涉类型系统、并发模型与计算范式的深层差异，稍有不慎就会埋下性能隐患或逻辑错误。

用 size() 方法获取集合长度

Java 所有标准集合类（ArrayList、HashSet、LinkedList、HashMap 的 keySet() 等）都继承自 Collection 或实现其子接口，因此统一提供 size() 方法。它返回 int 类型，表示当前实际元素个数。

注意：该值是实时计算的（多数实现直接返回内部计数器字段），不是遍历统计，所以时间复杂度为 O(1)。

常见误用：
- 对 null 集合调用 size() → 抛出 NullPointerException
- 误以为 HashMap.size() 返回的是“键值对数量”以外的东西（其实它就是键值对个数）

示例：

List<String> list = new ArrayList<>();
list.add("a");
list.add("b");
System.out.println(list.size()); // 输出 2

length 和 length() 别混了

数组用 length（字段，不是方法），字符串用 length()（方法），集合一律用 size()。三者语法和语义完全不同，不能互换。

典型错误写法：

List<Integer> nums = Arrays.asList(1, 2, 3);
System.out.println(nums.length);     // 编译错误！List 没有 length 字段
System.out.println(nums.length());   // 编译错误！List 没有 length() 方法
System.out.println(nums.size());     // 正确

容易混淆的场景：

• 把 String[] arr 当作集合 → 用 arr.length，不是 arr.size()
• 把 String s 当作集合 → 用 s.length()，不是 s.size()
• 流式处理后想查数量 → stream.count() 返回 long，且会触发终端操作，不可复用流

并发集合的 size() 可能不准

ConcurrentHashMap、CopyOnWriteArrayList 等并发集合的 size() 不保证强一致性。在高并发写入过程中调用，可能返回近似值（比如 ConcurrentHashMap.size() 实际是分段统计再汇总，期间有更新可能被漏计）。

如果你需要精确计数且写操作频繁：

• 改用 AtomicInteger 手动维护计数（配合增删逻辑）
• 或加锁后调用（牺牲并发性）
• 避免在性能敏感路径中反复调用 size() 判断空/满 —— 改用 isEmpty() 更高效（多数实现也是 O(1) 且不涉及汇总）

示例（不推荐用于精确判断）：

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
// 多线程往里 put...
if (map.size() > 1000) { // 这个判断可能滞后或跳变
    triggerCleanup();
}

Stream 流不能靠 size() 查数量

流对象（Stream）本身没有 size() 方法。试图调用会编译失败。

要获取流中元素个数，必须使用终端操作 count()：

List<String> list = Arrays.asList("a", "b", "c");
long count = list.stream().filter(s -> s.length() > 0).count(); // 返回 long

但要注意：

• count() 是终端操作，流无法复用
• 对无限流（如 Stream.iterate）会永远阻塞
• 性能上不如直接用集合的 size() —— 如果原始数据本就是集合，别先转流再数

更隐蔽的问题：某些中间操作（如 distinct()）会让 count() 变成 O(n) 甚至更高，而原集合的 size() 始终是 O(1)。

集合长度这件事，表面看只是调一个方法，但背后牵扯到类型区分、并发语义、流式计算模型这些容易被忽略的层次。尤其当代码从单线程迁移到多线程，或从集合直用转向 Stream API 时，size() 的行为差异就会立刻暴露出来。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java集合元素数量计算方法》文章吧，也可关注golang学习网公众号了解相关技术文章。