ArrayList 的 size() 方法时间复杂度为 O(1)，直接返回内部 size 字段值，该字段在增删操作中同步更新，与底层数组容量 elementData.length 无关。

size() 方法在 ArrayList 中怎么算长度

ArrayList 的 size() 是 O(1) 时间复杂度，它不遍历元素，而是直接返回内部字段

常见误解是认为 size() 会调用 elementData.length ——其实不是：elementData.length 是底层数组容量（capacity），而 size 是当前实际元素个数（size）。二者经常不等。

public class ArrayList {
    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。

• 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 子类都如此。