队列长度需权衡等待与拒绝，应匹配任务类型、流量节奏及线程能力：CPU型用SynchronousQueue或小容量ArrayBlockingQueue；I/O型设20～200；混合型按“峰值TPS×平均耗时÷1000”估算并留余量。

排队队列长度不是越大越好，也不是越小越稳——它本质是在“等”和“拒”之间做权衡：队列太长，任务积压导致延迟飙升；队列太短，拒绝频繁又浪费处理能力。关键在于让队列容量与任务到达节奏、线程消费能力、业务容忍度三者对齐。

按任务类型匹配队列容量

不同类型的任务对缓冲需求差异很大，不能统一设值：

• CPU密集型：任务执行快、几乎不等待，队列只需应对瞬时抖动。推荐用 SynchronousQueue（容量为0）或 ArrayBlockingQueue(32–128)；避免任务在队列中空等，浪费响应时效
• I/O密集型：如调数据库、发HTTP请求，单任务耗时长、CPU空闲率高，可适度缓冲。队列设为 20～200（不建议超500），优先靠扩容线程消化压力，而非堆大队列
• 混合型/真实业务：例如订单创建含校验、三方调用、写库三段。用公式粗估：队列长度 ≈ 峰值TPS × 平均耗时（ms） ÷ 1000。例：峰值500 QPS、平均80ms → 理论40，实际取64并留余量

从流量节奏出发设初始值

队列是生产者（提交端）和消费者（工作线程）之间的缓冲带，必须反映二者速率差：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 先监控「每秒提交数」和「每秒完成数」，若长期不等，说明队列与线程配置失配
• 保守起步：取预估峰值下 5～10秒的任务积压量 作为初始上限。例如QPS=100、平均耗时150ms → 初始队列≈75～150
• 避免凭感觉填1000或Integer.MAX_VALUE——无界队列等于把背压交给JVM堆内存，下游一慢，OOM就在几秒内发生

结合线程行为动态判断是否该调队列

队列填充率不是独立指标，必须和活跃线程数一起看：

• 若队列填充率 > 80% 且 活跃线程数 ：说明任务执行慢（如慢SQL、超时调用），应优化单任务耗时，而非加队长
• 若队列填充率高 且 活跃线程已达上限：才考虑小幅上调队列（如+20%），同时检查最大线程数是否受DB连接池、HTTP客户端等下游资源约束
• 持续低填充率（

配套动作必须到位

只调数字不管配套，等于白配：

• 一律禁用 LinkedBlockingQueue() 无参构造；必须显式指定容量，如 new ArrayBlockingQueue(128)
• 拒绝策略必须显式指定：生产环境推荐 CallerRunsPolicy（调用线程自己执行，天然限流）或自定义策略（记录+告警）
• 上线后盯紧两个指标：getActiveCount()（活跃线程数）、getQueue().size()（当前排队数），发现异常及时干预

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南