Java集合统一用size()方法获取长度，返回int型元素个数，时间复杂度O(1)；注意null调用抛NPE、并发集合size()可能不准、Stream无size()需用count()。
用 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()。三者语法和语义完全不同，不能互换。
立即学习“Java免费学习笔记（深入）”；
典型错误写法：
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<t></t>）本身没有 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() 的行为差异就会立刻暴露出来。
