是，绝大多数标准Java集合的size()为O(1)，但Stream.count()、自定义重写size()的集合及Arrays.asList(基本类型数组)等例外场景为O(n)或语义异常。
集合 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() —— 这会创建中间集合，浪费内存和时间。
推荐做法：
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 用
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;
实际项目里，size() 看似简单，但混用 Stream、包装类、基本类型数组、并发容器时，行为差异很容易被忽略。关键不是“怎么调用”，而是“调用对象的真实类型和实现契约”。 
