线程池资源预分配的核心是提前创建corePoolSize范围内的核心线程，通过prestartAllCoreThreads()方法实现“即刻就位”，避免任务来临时的创建延迟；预分配数量需依CPU密集型（≈CPU核数+1）或I/O密集型（×2～3）等业务特征确定，并配合keepAliveTime、allowCoreThreadTimeOut及监控进行动态调优，避免在低频、长耗时或SynchronousQueue场景下盲目预分配。
线程池资源预分配，核心是让关键线程“提前就位”，避免任务来临时才创建线程带来的延迟。它不是简单地把最大线程数全拉满，而是有策略地在系统空闲或启动阶段，就把一部分线程准备好，随时响应请求。
预分配什么？重点是核心线程
预分配的对象主要是 corePoolSize 范围内的线程。这些线程一旦创建，只要没被主动关闭或超时回收，就会一直驻留在线程池中。它们是响应速度的“第一道防线”。
- 调用 prestartAllCoreThreads() 方法，可强制线程池立即创建并启动全部核心线程，而不是等第一个任务提交时才懒加载
- 对启动即高负载的服务（如网关、定时批处理入口），在应用初始化完成、正式接收流量前执行该方法，能显著缩短首波请求的响应时间
- 不建议对非核心线程做常规预分配，因为它们本就是为应对突发流量而设计的弹性资源
预分配多少？按业务特征定基线
数量不是拍脑袋决定的，需结合任务类型和硬件基础：
- CPU密集型任务（如图像压缩、数值计算）：预分配数 ≈ CPU逻辑核数 + 1，避免过多线程争抢CPU导致频繁上下文切换
- I/O密集型任务（如数据库查询、HTTP调用）：预分配数可设为 CPU核数 × 2～3，因为线程常处于等待状态，多些线程能更好利用空闲周期
- 微服务场景下，若单个接口平均响应时间长、并发不高，预分配 4～8 个核心线程往往比盲目设为 50 更稳、更省资源
预分配后怎么管？避免“只生不养”
预分配不是一劳永逸。线程长期空闲也会浪费内存和句柄资源，需配合生命周期管理：
- 设置合理的 keepAliveTime（如 30～60 秒），让非核心线程在空闲后及时退出；核心线程默认不超时，但可通过 allowCoreThreadTimeOut(true) 开启其超时机制（慎用）
- 监控 activeCount 和 getQueue().size()，若发现长期大量线程空闲、队列几乎为空，说明预分配过量，可下调 corePoolSize
- 避免在低峰期仍维持过高预分配，尤其在容器化环境（如K8s）中，资源配额有限，过度预占会影响其他组件调度
哪些情况不适合强预分配？
预分配虽快，但并非万能。以下场景要谨慎：
- 任务到达极不规律、间隔长达分钟级以上：预分配线程长时间闲置，纯属资源浪费
- 单次任务执行时间远超普通水平（如持续数分钟的报表导出）：预分配会快速占满核心线程，后续短任务被迫排队，反而拖慢整体响应
- 使用 SynchronousQueue 的缓存型线程池（如 newCachedThreadPool）：它本身无队列、不预分配，靠动态伸缩，强行预分配违背其设计初衷
