ArrayList 的 size() 方法时间复杂度为 O(1)，直接返回内部 size 字段值，该字段在增删操作中同步更新，与底层数组容量 elementData.length 无关。
size() 方法在 ArrayList 中怎么算长度
ArrayList 的 size() 是 O(1) 时间复杂度，它不遍历元素，而是直接返回内部字段 size 的值。这个字段在每次 add()、remove()、clear() 等操作后都会被同步更新。
常见误解是认为 size() 会调用 elementData.length ——其实不是：elementData.length 是底层数组容量（capacity），而 size 是当前实际元素个数（size）。二者经常不等。
public class ArrayList<E> {
transient Object[] elementData;
private int size; // ← size() 就是直接 return 这个
public int size() {
return size;
}
}
- 扩容不会改变
size，只影响elementData.length - 调用
trimToSize()后，elementData.length会收缩到等于size，但size()值不变 - 如果手动反射修改了
size字段（不推荐），size()返回值会立即变化，但集合状态将不一致
LinkedList 的 size() 为什么也是 O(1)
Java 8+ 的 LinkedList 内部维护了 size 字段，和 ArrayList 一样，size() 直接返回该字段。早期版本（Java 6）曾用遍历计数，但早已废弃。
注意：虽然时间复杂度是 O(1)，但 LinkedList 的内存开销更大（每个节点含前后指针），且缓存局部性差，所以即便 size() 很快，整体性能通常不如 ArrayList。
立即学习“Java免费学习笔记（深入）”；
-
addFirst()、addLast()、remove()都会原子性地更新size - 并发修改（如多线程未同步）可能导致
size()返回错误值，这不是方法问题，而是违反了集合的线程安全契约 - 不要用
size() == 0替代isEmpty()——虽结果等价，但isEmpty()语义更清晰，且部分集合（如某些懒加载实现）可能对isEmpty()做特殊优化
HashMap 和 HashSet 的 size() 返回的是键值对数量还是桶数量
HashMap.size() 返回的是当前已存放的键值对数量（即 size 字段），不是数组长度（table.length），也不是链表/红黑树节点总数（比如一个桶里有 5 个冲突节点，只算作 1 个 entry）。
HashSet 底层用的是 HashMap，它的 size() 实际调用的是内部 map.size()，所以也代表唯一元素个数。
-
size()不包含被标记为“已删除”但尚未 rehash 的旧节点（Java 8+ 的HashMap没有这种标记机制，删除即清理） - 调用
resize()（扩容）时，size字段不变，只是数据迁移到新数组 - 如果 key 的
hashCode()被恶意重写（始终返回相同值），会导致所有 entry 落入同一桶，size()仍准确，但查找退化为 O(n)
哪些集合的 size() 可能不是 O(1)
标准 JDK 集合中，所有实现了 Collection 接口的类（ArrayList、LinkedList、HashMap、TreeSet 等）的 size() 都是 O(1)。但要注意：
- 某些第三方库或自定义集合（如流式包装器、数据库游标代理）可能重写了
size()为惰性计算或真实扫描，例如Guava's AbstractIterator包装的集合可能没有预存 size -
Stream.count()不是size()，它是终端操作，必须消费整个流，O(n) - JDBC
ResultSet没有size()方法；调用last() + getRow()或getFetchSize()都不能可靠替代“集合长度”语义
真正容易出错的地方在于：把「接口类型」当成「实现行为」来假设。比如写泛型方法接受 Collection<?>，就默认 size() 是 O(1) ——这在 JDK 标准实现里成立，但无法保证所有 Collection 子类都如此。
