ConcurrentLinkedQueue 的 size() 方法时间复杂度为 O(n)，需遍历链表跳过已删除节点统计有效元素，高并发下调用会引发性能瓶颈；推荐改用 isEmpty()、业务侧计数器、缓存 size 结果或队列活跃度信号等替代方案。
ConcurrentLinkedQueue 的 size() 方法不是常量时间操作，而是必须遍历整个链表才能统计有效节点个数，时间复杂度为 O(n)。在高并发、大流量场景下，频繁调用它会迅速成为性能瓶颈，尤其对监控系统这类“旁路观察者”造成意外反噬。
为什么 size() 是 O(n)？
它没有维护全局计数器，每次调用都从头节点开始逐个检查：
– 跳过已标记为删除（item == null）的逻辑删除节点；
– 沿 next 指针一路向下，直到遇到 null；
– 遍历中还可能因并发修改导致指针跳跃或重试，进一步放大开销。
监控系统里调用 size() 的典型风险
很多团队会在日志、指标采集或健康检查中写类似这样的代码：
-
log.info("queue size: " + queue.size())—— 每次消费都打一次，QPS 上千时等于每秒遍历上千次链表； -
if (queue.size() > 10000) alert();—— 表面是阈值判断，实际触发的是全链表扫描； - 用
size()控制采样频率（如“每积压 500 条上报一次”），反而让采样本身成了积压主因。
替代方案：轻量、可靠、不拖慢主线程
真正适合监控场景的做法不是“少调用”，而是“换思路”：
- 用
isEmpty()替代size() == 0—— 它只比对 head/tail 引用，是 O(1) 且线程安全； - 业务侧主动维护一个
LongAdder或AtomicLong，在offer()和poll()时增减，供监控读取（注意：需权衡额外 CAS 开销）； - 监控线程定期（如每 5 秒）调用一次
size()并缓存结果，前端展示用缓存值，避免实时拉取； - 完全放弃精确长度，改用“队列活跃度”信号：比如连续 N 次
poll()返回 null，说明空闲；连续 M 次offer()后未被消费，可间接提示积压趋势。
真实翻车现场：CPU 100% 却不处理消息
某网关在流量突增时 CPU 打满，但下游收不到任何消息。jstack 显示大量线程卡在 ConcurrentLinkedQueue.size() 的 for 循环里——不是锁住了，而是每个线程都在疯狂遍历一条越来越长的链表。根源就是监控日志里那行 "pending: " + queue.size() 被放在了每条消息的消费路径上。
