Java Queue底层源码为何通过遍历获取大小而非维护静态变量？

首先要明确：Java的Queue是接口，其通用抽象实现AbstractQueue的size()方法确实采用遍历计数的方式，但像LinkedList这类同时实现List和Queue的子类，会重写size()用维护的字段直接返回——这种差异源于不同实现的设计权衡：

• 适配多样的队列特性：Queue的实现类场景差异极大，比如无界并发队列ConcurrentLinkedQueue，在高并发下维护一个准确的size变量需要频繁的CAS操作，会大幅拉高入队、出队的性能开销；而遍历获取size虽然是O(n)复杂度，但这类场景下size()通常不是高频调用，牺牲非核心操作的性能来保障核心入队出队的高效，是更合理的选择。AbstractQueue的遍历实现是一种通用兜底方案，能适配所有无法低成本维护size的队列实现。
• 避免状态一致性风险：维护size变量要求所有修改队列结构的操作（入队、出队、清空等）都同步更新该变量，一旦遗漏就会导致数据不一致。对于复杂的队列实现（比如优先级队列、阻塞队列），这种同步逻辑会增加代码复杂度和出错概率。
• 给子类留优化空间：AbstractQueue提供的是最通用的实现，子类可以根据自身场景重写size()——比如LinkedList作为List实现，size()是高频调用场景，维护一个size字段能以极低的成本实现O(1)的查询效率，所以它选择重写该方法。

这里的“实体”应该指额外的状态变量（比如跟踪大小的size字段），这个设计原则是成立的，核心原因包括：

• 减少维护成本：额外的状态变量需要在所有结构修改操作中同步更新，逻辑上多了一层需要保证一致性的点，增加了代码出错的概率。
• 降低性能开销：每次修改操作都要更新状态变量，在高并发场景下会带来额外的同步或原子操作成本，拖慢核心业务操作的速度。
• 简化实现逻辑：最小化状态量能让代码结构更简洁，更容易理解、调试和维护。

当然这不是绝对的：如果某个状态是高频使用的，且维护它的开销远小于每次计算的成本，那维护该状态就是合理的（比如LinkedList的size字段）。

内容的提问来源于stack exchange，提问作者wb lin