Java线程池的排队与等待由参数组合主动控制：队列类型（Array、Synchronous、LinkedBlockingQueue）决定排队行为，keepAliveTime和allowCoreThreadTimeOut调节空闲线程，拒绝策略实现可控降级，动态调参适配真实负载。
Java线程池的任务排队和等待时间不是被动“等出来”的，而是由参数组合主动控制的结果。关键不在延长等待，而在让任务在合适的位置、以合适的节奏被处理——避免积压、减少空等、防止雪崩。
队列类型决定排队行为本质
任务是否排队、排多久、排多深，首先取决于你选的 BlockingQueue：
- ArrayBlockingQueue（有界队列）：容量固定，写入满时触发线程扩容或拒绝策略。适合对资源敏感的系统，能明确限制内存占用，但需预估合理容量（如1000–10000），过小易频繁触发拒绝，过大则失去保护意义。
- SynchronousQueue（同步移交队列）：不存储任务，每个提交必须立刻由空闲线程接收；若无空闲线程，则立即创建新线程（直到达 maximumPoolSize）。适合低延迟、高吞吐场景，但要求 corePoolSize 设置合理，否则易快速耗尽线程数。
- LinkedBlockingQueue（默认无界队列）：构造时不传参即为 Integer.MAX_VALUE 容量，看似“无限”，实则极易因任务持续涌入导致 OOM。仅适用于任务到达平稳、执行极快、且总量可控的后台批处理。
等待时间由线程空闲与队列填充共同调节
用户感知的“等待时间”实际是两段延迟叠加：任务在队列中排队的时间 + 线程从队列取任务开始执行的延迟。优化方向是压缩这两段：
- 缩短队列排队：用 SynchronousQueue 或小容量 ArrayBlockingQueue，配合足够 corePoolSize，让任务尽量不排队，直接交由线程执行。
- 控制线程空闲：非核心线程 keepAliveTime 建议设为 30–60 秒；核心线程默认永驻，若业务存在明显波谷期，可调小 keepAliveTime 并设 allowCoreThreadTimeOut(true)，让核心线程也能回收。
- 避免“等满再扩”陷阱：ThreadPoolExecutor 默认必须等队列满才扩容。若业务对堆积敏感（如实时通知），可通过自定义 queue（如继承 LinkedBlockingQueue 并重写 offer()）在队列使用率达 70% 时提前触发扩容逻辑。
拒绝策略是排队失控时的最后一道闸门
当队列已满、线程已达上限，拒绝不是失败，而是可控的降级信号：
立即学习“Java免费学习笔记（深入）”；
- CallerRunsPolicy：让提交线程自己执行任务，天然限流，适合削峰保稳，但会阻塞调用方，慎用于 Web 请求入口。
- DiscardOldestPolicy：丢弃队列头最老任务，适合任务有时效性（如行情推送），新任务优先。
- 自定义策略：记录被拒任务日志 + 上报监控指标 + 异步落库重试，实现可观测、可追溯、可补偿。
动态适配比静态配置更贴近真实负载
固定参数难以应对流量波动。可基于运行时指标做轻量级自适应：
- 每 5–10 秒检查 activeCount / poolSize 比值（负载率）；
- 负载率 > 0.8 且队列深度持续上升 → 增大 maximumPoolSize（每次+1～2）；
- 负载率
- 注意：maximumPoolSize 变更需配合队列类型（SynchronousQueue 或小容量 ArrayBlockingQueue 更适配动态扩缩）。
