LinkedBlockingQueue默认容量为Integer.MAX_VALUE，表面无界实则易致OOM，必须显式设置合理容量、配套拒绝策略并优先考虑ArrayBlockingQueue等更可控方案。
LinkedBlockingQueue 默认是无界的，capacity 设为 Integer.MAX_VALUE，表面看“够用”，实际极易因任务堆积引发 OOM。关键不是能不能设 capacity，而是**必须显式设、合理设、配合策略设**。
显式指定容量，禁用默认无界行为
不要用 new LinkedBlockingQueue() 这种无参构造——它等于开了个“无限缓存”。哪怕只是临时测试，也应明确上限：
-
正确写法：
new LinkedBlockingQueue(200)（比如限制最多缓存 200 个待处理任务） -
错误写法：
new LinkedBlockingQueue()或new LinkedBlockingQueue(Integer.MAX_VALUE) - 容量值需结合系统吞吐与内存预算估算：例如单任务对象平均占 10KB，200 个 ≈ 2MB 堆内存，可接受；若设成 10 万，就接近 1GB，风险陡增
搭配拒绝策略，让队列满时有出路
光设容量不够，队列满了得知道怎么处理。否则 submit() 会阻塞或抛异常，影响上游逻辑：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐使用
CallerRunsPolicy：由调用线程自己执行任务，自然降低提交速率，形成负反馈 - 避免用
AbortPolicy（直接抛异常）在核心链路中，除非你已做好重试/降级 - 不建议用
DiscardPolicy或DiscardOldestPolicy处理关键业务任务，易丢数据
优先考虑 ArrayBlockingQueue 替代方案
如果对内存敏感、要求强确定性，ArrayBlockingQueue 是更稳妥的选择：
立即学习“Java免费学习笔记（深入）”；
- 底层是固定大小数组，内存占用可预估、不可扩容，杜绝“悄悄膨胀”
- 构造时强制传入容量，从编码层面杜绝无界误用：
new ArrayBlockingQueue(50) - 虽吞吐略低于 LinkedBlockingQueue，但在大多数 Web/API 场景下差异不明显，稳定性收益更高
动态调整 capacity？谨慎评估必要性
有方案通过自定义队列（如改写 capacity 为 volatile 字段）实现运行时扩容，但实际收益有限：
- 扩容不能解决根本问题——若任务持续大于处理能力，只是推迟 OOM 时间
- 动态修改需同步通知所有生产者/消费者，易引入竞态或状态不一致
- 真正需要的是监控 + 自动扩缩容（如基于队列长度触发告警、降级或弹性伸缩），而非单纯调大 capacity
