Java线程池的并发扩展能力依赖可控的资源复用机制，由corePoolSize、maximumPoolSize和keepAliveTime三参数联动实现弹性伸缩，并通过队列与拒绝策略形成背压反馈闭环，辅以预热与监控保障高并发稳定性，而虚拟线程则为I/O密集型场景提供百万级并发新路径。
Java线程池对系统并发扩展能力的支持，核心不在于“无限加线程”，而在于**可控、可预测、可回收的资源复用机制**。它通过参数协同与运行时反馈，把“并发压力”转化为可调度、可观测、可干预的系统行为。
线程数量弹性伸缩依赖三要素联动
线程池不是静态容器，而是动态调节系统负载的执行中枢。其扩展能力由三个参数共同决定：
- corePoolSize：稳态承载基线流量。这部分线程常驻内存，响应快、无创建开销，适合处理持续、规律的请求；
- maximumPoolSize：应对突发峰值的上限。只有当任务队列已满且核心线程全忙时，才触发创建非核心线程；
- keepAliveTime：控制弹性收缩。超出核心数的线程空闲超时后自动销毁，避免资源长期闲置。
三者配合，使线程池在低峰期保持轻量，在高峰期快速扩容，高峰回落又能及时释放——这是“按需伸缩”的底层逻辑。
任务排队与拒绝策略构成背压反馈闭环
线程池不靠盲目扩容来扛压，而是用队列和拒绝策略把压力“显性化”：
立即学习“Java免费学习笔记（深入）”；
- 当任务提交速率 > 线程消费速率，任务先进入
workQueue缓冲，为系统争取缓冲时间； - 若队列也溢出（如使用有界队列），则触发
RejectedExecutionHandler——这不是失败，而是关键信号； - 选用
CallerRunsPolicy时，由调用方线程同步执行任务，天然降低上游提交速度，形成反压； - 自定义拒绝处理器可记录拒绝次数、触发告警或降级逻辑，让扩容决策有据可依。
预热与监控是高并发落地的必要支撑
参数再合理，若缺乏运行时感知和启动准备，仍会遭遇冷启动抖动或盲调风险：
- 应用启动后调用
prestartAllCoreThreads()，让所有核心线程就绪待命，避免首波请求触发逐个建线程的延迟； - 实时采集
getActiveCount()（活跃线程）、getQueue().size()（排队数）、拒绝任务计数等指标； - 当活跃线程持续接近
maximumPoolSize、队列长度持续增长，说明当前配置已达瓶颈，应触发扩容预案或限流干预； - 动态扩容不建议直接调用
setCorePoolSize()，推荐两级池架构或配置中心驱动重建，确保状态一致与安全。
虚拟线程正在重构并发扩展的边界
传统平台线程受限于操作系统线程资源，通常千级并发即面临内存与调度压力。JDK 21+ 的虚拟线程提供了新路径：
- 每个虚拟线程仅占用约1KB栈空间，支持百万级并发连接；
- I/O阻塞时自动挂起，JVM在少量平台线程上高效调度大量虚拟线程；
- 适用于高吞吐、I/O密集型场景（如Web API、消息处理），无需重写业务逻辑即可接入；
- 但CPU密集型任务仍应使用固定大小的平台线程池，避免调度开销反噬性能。
