无界队列不具备“非阻断性膨胀边界”，其内存爬升是任务积压导致的持续性堆内存增长，表现为单调陡峭上升、无平台期、无回落，最终导向oom。

无界队列本身不具备“非阻断性膨胀边界”——这个说法存在概念混淆。无界队列（如 LinkedBlockingQueue() 默认构造）的实质是**逻辑上无容量限制、实践中不触发拒绝策略**，它不会主动膨胀，而是被动积压；所谓“膨胀”，是任务持续提交、消费滞后导致的队列 size 持续增长，属于**内存泄漏式堆积**，而非设计上的弹性伸缩机制。

为什么不能靠“无界队列的膨胀”分析抖动下的内存爬升

网络极端抖动会引发下游响应延迟剧增、超时重试激增、连接堆积、异步回调滞留等连锁反应，但这些压力最终是否转化为 JVM 堆内存飙升，关键取决于线程池的**队列类型与拒绝策略**：

• 用无界队列时，任务照单全收，不拒、不丢、不降级——抖动越久，积压越多，每个待执行 Runnable 及其闭包引用的对象（如请求体、上下文、Future 回调）长期驻留堆中，GC 无法回收；
• 此时观察到的内存曲线是**单调陡峭上升、无平台期、无回落**，与抖动持续时间强正相关，但和抖动本身的“频率”或“幅度”无直接函数关系；
• 这种爬升不是瞬时的，而是秒级到分钟级的持续累积过程，背后没有“边界”，只有 OOM 的终点。

真正可分析的瞬时内存特征，来自有界队列+合理拒绝

若系统采用有界队列（如 ArrayBlockingQueue(1024)）并配置可监控拒绝策略（如 AbortPolicy 或自定义记录型策略），网络抖动期间会出现可识别的内存行为模式：

• 抖动初起：队列迅速填满 → 拒绝数突增 → 日志/指标中出现大量 “RejectedExecutionException”；
• 内存表现：活跃线程数稳定或小幅上升，但堆内存增长平缓甚至略降（因拒绝任务不入队、不创建冗余对象）；
• 若配合熔断器（如 Sentinel 或 Hystrix），还会触发 fallback 逻辑，此时内存占用取决于 fallback 实现复杂度，但整体可控。

抖动场景下更应关注的内存指标组合

单看堆内存曲线意义有限，需关联以下维度交叉诊断：

• 线程池运行态：`queue.size()`、`activeCount()`、`completedTaskCount` 增速比；
• JVM GC 表现：Young GC 频次未明显上升，但 Old GC 失败或 Full GC 次数增加 → 指向长期存活对象堆积（典型如无界队列中的任务）；
• 网络层信号：`ss -i` 查看重传率（retrans）、`netstat -s | grep "packet reassemblies"` 看分片重组失败 → 定位抖动源头是否在 TCP 层；
• 应用层日志节律：异步任务 submit 时间戳与实际 execute 时间戳差值（即 queue wait time）持续 > 5s，即为积压明确信号。

务实建议：用“抖动注入 + 队列监控”代替理论膨胀分析

与其试图拟合无界队列的“膨胀边界”，不如在测试环境中主动模拟抖动，并观测真实行为：

• 用 tc netem 在服务端注入 200ms ±100ms 延迟、5% 丢包，持续 2 分钟；
• 将线程池队列替换为 LoggingLinkedBlockingQueue（继承后重写 offer，记录 size 超过阈值时的堆栈）；
• 采集 Prometheus 指标：thread_pool_queue_size{pool="biz"}、jvm_memory_used_bytes{area="heap"}、http_client_request_duration_seconds_max{client="downstream"}；
• 观察三者时间轴对齐关系：当下游延迟曲线上扬 1s 后，队列 size 是否在 3s 内突破 1000？堆内存是否在 10s 后开始加速上升？