keepAliveTime仅作用于超出corePoolSize的非核心线程，需配合allowCoreThreadTimeOut(true)才影响核心线程；workQueue不是越大越好，有界队列（如ArrayBlockingQueue）配合理keepAliveTime和拒绝策略构成稳定“三件套”，无界队列易致OOM，SynchronousQueue则极度依赖keepAliveTime调优。
keepAliveTime 和 workQueue 是线程池稳定运行的两个关键杠杆。它们不直接决定吞吐量上限，但共同决定了系统在流量波动时是平稳过渡，还是突然雪崩。
keepAliveTime 的真实作用和常见误用
它只对超出 corePoolSize 的非核心线程生效——核心线程默认永不回收，除非显式调用 allowCoreThreadTimeOut(true)。很多人误以为设了 keepAliveTime 就能“自动缩容”，其实没配这个开关，再多空闲线程也一直挂着。
设置过短（比如 1 秒）会导致突发流量后线程频繁创建销毁，CPU 消耗反升；设得太长（比如 30 分钟），又会让低峰期空闲线程白白占内存和句柄资源。
- CPU 密集型任务：建议 keepAliveTime = 0，避免线程回收再创建的开销，让非核心线程用完即退
- IO 密集型且请求有明显波峰波谷：设为 60–180 秒，兼顾响应速度与资源释放
- 长期稳定服务（如定时批处理）：可设为 5–10 分钟，减少抖动
- 动态调整时，必须同步调用
allowCoreThreadTimeOut(true)才对核心线程起效
workQueue 不是“越大越好”，而是“刚好够用”
队列不是缓冲区，它是压力传导器。选错队列，等于把背压延迟从线程调度层转移到内存或下游系统上。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- ArrayBlockingQueue（有界）：容量必须明确设定（如 200）。适合对稳定性要求高的场景，能配合拒绝策略快速失败，防止 OOM。但容量太小会频繁触发拒绝，太大则掩盖真实瓶颈
- LinkedBlockingQueue（无界）：默认容量 Integer.MAX_VALUE，看似“永不拒绝”，实则极易导致内存溢出。仅适用于任务提交速率极其平稳、且单任务内存占用极低的内部调度场景
- SynchronousQueue（无缓冲）：不存任务，靠线程“手递手”交接。适合高吞吐、低延迟场景（如网关转发），但要求线程创建能力足够强，否则任务直接被拒绝
判断依据很简单：如果任务平均到达速率持续高于处理速率，就必须用有界队列，并配合合理的拒绝策略（如 CallerRunsPolicy 让调用方降速）。
keepAliveTime 和 workQueue 要联动看
两者不是孤立参数。例如：
- 用了 SynchronousQueue，keepAliveTime 就特别关键——因为没队列缓冲，所有压力都落在线程伸缩上，此时 keepAliveTime 过长会导致空闲线程滞留，过短又引发抖动
- 用了大容量 LinkedBlockingQueue，keepAliveTime 几乎失效——任务全堆在队列里，线程数卡在 corePoolSize，根本不会扩容到 maximumPoolSize
- ArrayBlockingQueue + 合理 keepAliveTime + AbortPolicy，构成最可控的“三件套”，适合多数 Web API 场景
真正有效的调优，是让这两个参数一起回答一个问题：当每秒涌入 500 个请求，而当前只能处理 300 个时，系统该排队、该拒绝、还是该扩容？答案就藏在这两个参数的组合里。
