防止大促oom的关键是合理配置线程池四参数：选用有界队列（如arrayblockingqueue(200)）、设合理core/max线程数（cpu密集型core=核数+1，io密集型core=核数×2～3）、配callerrunspolicy等拒绝策略、监控queue.size/activecount/完成率。

防止大促期间因任务排队导致 OOM，关键不是堆更多内存，而是让线程池在资源可控前提下“该拒就拒、该限就限、该控就控”。核心在于用好 corePoolSize、maximumPoolSize、workQueue 和 handler 这四个参数的组合逻辑，切断无界堆积链路。

选有界队列，堵住内存泄漏源头

LinkedBlockingQueue 默认无界（容量 Integer.MAX_VALUE），是大促 OOM 的头号诱因。哪怕只设 1000 容量，也比不设强十倍。

• 优先用 ArrayBlockingQueue(200)：简单、可控、显式限流，适合订单创建、支付回调等关键路径
• 慎用 LinkedBlockingQueue：如必须用，务必指定容量，例如 new LinkedBlockingQueue(500)
• 避免 SynchronousQueue：它不存任务，但会强制立即扩容线程，大促时易触发 maximumPoolSize 爆炸，CPU 上下文切换飙升

设合理线程边界，避免“线程雪崩”或“卡死不动”

核心线程数不是越多越好，最大线程数也不是越大越稳——要匹配你的服务器能力和任务特征。

Preqstation

一款AI工具，主要用于将PREQSTATION编码任务委派给Claude Code、Codex CLI或Gemini CLI，采用PTY安全执行（工作目录+后台+监控），适合需要提升相关任务效率的用户。

下载

• CPU 密集型任务（如风控计算、加密解密）：corePoolSize = CPU 核数 + 1，maximumPoolSize ≤ corePoolSize × 2，防止频繁切换
• IO 密集型任务（如调第三方 HTTP、DB 查询）：corePoolSize = CPU 核数 × 2～3，maximumPoolSize = corePoolSize + 4～8，留出弹性空间
• 绝对禁止 maximumPoolSize = Integer.MAX_VALUE —— 这等于把线程创建权交给洪水，不是弹性，是失控

配拒绝策略，把风险转为可观测行为

队列满 + 线程满 ≠ 系统崩溃，而应是“有策略地降级”。默认 AbortPolicy 抛 RejectedExecutionException，适合能快速失败重试的场景；CallerRunsPolicy 更适合大促保底。

• CallerRunsPolicy：由提交任务的线程（比如 Tomcat worker 线程）同步执行任务，天然限流，且不丢任务、不抛异常、不新建线程
• 自定义拒绝策略：记录日志 + 上报监控 + 触发告警 + 调用降级 fallback（如返回缓存、简化流程），比静默丢弃更可靠
• 禁用 DiscardPolicy 和 DiscardOldestPolicy：大促时丢任务=丢单=丢钱，不可接受

加基础监控，让参数配置可验证

调优不是一次配置完就结束，得靠运行时指标反哺决策。这几个值必须实时采集并设阈值告警：

• executor.getQueue().size()：超过队列容量 70%，说明处理能力已持续承压
• executor.getActiveCount()：长期接近 maximumPoolSize，说明线程扩容已到极限
• executor.getCompletedTaskCount() 与提交量对比：完成率持续低于 95%，大概率存在阻塞或慢任务