Java集合元素统计方法详解

Java集合的size()方法看似简单，实则暗藏玄机：虽然ArrayList、HashMap等标准集合的size()确实是O(1)常数时间操作，但Stream.count()、自定义重写size()的集合、Arrays.asList(基本类型数组)等场景却可能退化为O(n)甚至产生语义陷阱；本文深入剖析了过滤计数的高效写法、Map视图size的一致性、ConcurrentHashMap的近似性陷阱，以及基本类型数组误用导致size恒为1的经典坑点——掌握这些细节，才能在性能敏感和高并发场景下写出真正健壮、高效的集合统计逻辑。

集合 size() 方法是否总是 O(1)？

绝大多数标准 Java 集合（ArrayList、HashSet、HashMap、LinkedList 等）的 size() 方法确实是 O(1) 时间复杂度，因为它们内部维护了计数器字段。但要注意：Stream 或 Iterator 构造的惰性集合（如 Stream.count()）不是直接查字段，而是遍历计数，属于 O(n)。

常见误用场景：

• 对 stream().filter(...).count() 反复调用，以为和 list.size() 一样快
• 把 Collection 接口变量当成具体实现，忽略了某些自定义集合可能重写 size() 为遍历实现（虽不推荐，但合法）

如何安全统计过滤后的元素数量？

如果需要的是「满足某条件的元素个数」，不要先 filter().collect() 再取 size() —— 这会创建中间集合，浪费内存和时间。

推荐做法：

• 用 stream().filter(...).count()：语义清晰，JVM 通常能优化成遍历计数，不建新集合
• 用传统 for 循环 + 计数器：在性能敏感且逻辑简单时更可控，避免 Stream 开销
• 避免 stream().filter(...).toList().size()：尤其当原始数据量大时，toList() 会分配完整新容器

long count = list.stream()
    .filter(item -> item.isActive() && item.getScore() > 80)
    .count(); // ✅ 正确：只计数，不建列表

Map 的 size() 和 keySet().size() 有区别吗？

没有本质区别。HashMap、TreeMap 等标准实现中，map.size() 和 map.keySet().size() 返回相同值，且都为 O(1)。因为 keySet() 是视图（View），其 size() 直接委托给底层 map。

但要注意：

• map.entrySet().size() 同样是 O(1)，不要误以为 entrySet 是“额外构造”而回避它
• 若使用 Collections.synchronizedMap() 包装，size() 仍为 O(1)，但会加锁 —— 在高并发读场景下，可考虑缓存 size 值（需自行保证一致性）
• ConcurrentHashMap 的 size() 是近似值（基于分段统计），严格场景应改用 mappingCount()（返回 long，更准确）

为什么 Arrays.asList(arr).size() 有时不符合预期？

这是最常踩的坑之一：Arrays.asList() 返回的是固定大小列表（ backed by the original array），它的 size() 确实反映数组长度，但**不能 add/remove**。如果后续误调用 add()，会抛 UnsupportedOperationException，此时 size 不再可信（因操作失败，但 size 未变）。

更隐蔽的问题：

• 传入基本类型数组（如 int[]）时，Arrays.asList(intArr) 不会拆箱，而是把整个数组当作单个元素 → size 恒为 1
• 正确做法：对基本类型，先用 IntStream.of(arr).boxed().collect(Collectors.toList())，或直接用 arr.length

// ❌ 错误：int[] 被当做一个 Object 元素
int[] nums = {1, 2, 3};
List<?> list = Arrays.asList(nums); // size == 1

// ✅ 正确：获取原始数组长度
int count = nums.length;

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。