ArrayBlockingQueue内存保护的关键是容量约束、显式背压与可控拒绝，需基于实测对象大小设定队列容量，统一使用带超时offer()并降级处理，消费者吞吐须匹配生产者，且需与JVM参数协同对齐。
在自定义组件中用 ArrayBlockingQueue 实现内存保护，核心不是“堵住”内存增长，而是通过容量约束 + 显式背压 + 可控拒绝，把物理内存占用稳定在预设上限内。关键在于队列容量要与单元素平均内存开销对齐，且所有入队路径必须统一受控。
容量设定必须基于真实对象体积
不能凭空设 1024 或 8192 这类“看着顺眼”的数字。需实测典型数据对象（含其引用的子对象）的 shallow size 和 retained size：
- 用 JOL（Java Object Layout）或 VisualVM 的 Memory Analyzer 测单个对象实际占多少字节
- 假设平均每个元素占 4KB，目标内存上限为 64MB，则理论最大容量 ≈ 64 × 1024 ÷ 4 = 16384
- 再预留 10% 冗余（GC 暂时无法回收、数组对象自身开销等），最终设为
new ArrayBlockingQueue<>(14700)
所有生产者必须使用带超时的 offer()，并处理失败
禁止使用 put()（无界阻塞）或不检查返回值的 offer()。统一走非阻塞+退避策略：
- 优先尝试
queue.offer(item, 50, TimeUnit.MILLISECONDS) - 返回 false 时，说明队列满 —— 此刻不能丢弃、不能重试无限循环，而应触发降级逻辑：如采样丢弃、写入本地磁盘暂存、或向监控系统发告警
- 避免在高并发下因频繁失败导致线程自旋耗尽 CPU
消费者必须保持稳定吞吐，防止队列持续积压
队列只是缓冲，不是存储。若消费速度长期低于生产速度，再大的容量也会被填满：
- 消费者线程数不宜少于生产者，建议按 1.2~1.5 倍配比，并监控
queue.size()的 P95 趋势 - 消费逻辑避免同步 I/O、远程调用等长耗时操作；耗时操作应异步化或移交专用线程池
- 可加简单健康检查：若
queue.size() > capacity * 0.8持续 30 秒，自动触发告警并记录堆快照
配合 JVM 参数形成闭环防护
ArrayBlockingQueue 管的是应用层逻辑内存，需与 JVM 层协同：
- 设置合理堆上限（
-Xmx），并启用-XX:+UseG1GC，避免 Full GC 触发时队列对象无法及时释放 - 开启
-XX:+PrintGCDetails，观察老年代增长是否与队列生命周期强相关 - 必要时配合
-XX:MaxMetaspaceSize防止动态代理、反射类加载引发元空间溢出，间接影响堆可用内存
不复杂但容易忽略 —— 真正的内存保护不在队列本身，而在容量、对象大小、吞吐节奏、JVM 行为这四者的严格对齐。
