服务使用 ConcurrentLinkedQueue 缓存待发送通知，流量高峰后队列持续增长且监控中的 size 不稳定，如何定位无界堆积、建立准确监控并实现限流与降级？

我会先把问题拆成三个方面：队列是否无界堆积、监控指标是否可信，以及生产速度超过消费能力时如何做背压和降级。

ConcurrentLinkedQueue 本身是无界非阻塞队列，offer 基本不会因为容量不足失败。它的 size() 需要遍历节点，在并发生产和消费过程中只能得到某一时刻的近似值，结果可能变化，也有一定性能开销，所以不能把它作为高并发场景下的精确监控指标。监控中 size 不稳定不一定代表数据丢失，可能只是统计时队列正在并发变化，但如果入队速率长期大于出队速率，队列节点和通知对象会持续占用堆内存，最终可能触发频繁 GC 甚至 OOM。

定位时我会先增加生产和消费两侧的累计计数，例如入队总数、出队总数、发送成功数、发送失败数、重试数、丢弃数，以及当前正在处理的任务数。队列积压量可以通过入队总数减去已完成或已出队总数来估算，而不是频繁调用 size()。同时记录入队速率、消费速率、发送耗时、线程池活跃数、任务拒绝数、下游接口响应时间和错误率，并结合 GC、堆使用率、线程池队列、数据库或网络依赖的监控，判断瓶颈是在生产端、消费端、下游服务还是重试逻辑。

如果