资源受限下保障高可用的关键是让线程池懂业务节奏，需按任务类型（CPU/IO/混合型）动态配置corePoolSize、有界workQueue和maximumPoolSize，并采用CallerRunsPolicy拒绝策略、allowCoreThreadTimeOut及自定义ThreadFactory，再通过三类指标持续调优。
在资源受限环境下保障变量任务的高可用处理，关键不是堆线程数，而是让线程池“懂业务节奏”——能稳住日常流量、扛住突发峰值、不拖垮系统。核心在于根据任务特征动态匹配参数，而非套用固定公式。
识别任务类型与资源边界
先明确两个硬约束：可用 CPU 核心数（Runtime.getRuntime().availableProcessors()）、最大堆内存与预期并发量。再判断任务本质：
- CPU 密集型（如批量计算、加解密）：线程数过多会加剧上下文切换，CPU 使用率反而下降；应以「核数 + 1」为基线，避免超过核数 × 2
- IO 密集型（如 HTTP 调用、DB 查询）：线程大部分时间在等待，可适度提高并发度；但需结合下游承载力（如数据库连接池大小、第三方接口 QPS 限流）反向约束最大线程数
- 混合型（常见于真实业务）：建议拆分线程池——计算类走小核心+短队列，IO 类走稍大核心+带限容队列，避免相互阻塞
核心参数配置要点
聚焦真正影响高可用的三个参数，其余保持合理默认即可：
- corePoolSize：设为可长期稳定运行的最小并发值。例如 4 核机器跑 IO 任务，监控显示平均活跃线程约 6 个，则 core 可设为 6～8，保证日常不排队、不扩容
- workQueue：必须用有界队列（如 ArrayBlockingQueue(200)）。无界队列在突发流量下会持续积压任务，吃光内存导致 OOM；容量按「平均 QPS × 平均响应时间 × 安全系数（1.5～2）」估算
- maximumPoolSize：设为资源上限允许的弹性峰值。例如内存允许最多支撑 30 个线程，且下游服务承诺支持 100 QPS，而单任务平均耗时 300ms，则理论最大并发 ≈ 100 × 0.3 = 30，maxPoolSize 就不宜超过 30
拒绝策略与存活机制增强韧性
高可用不只靠“多开线程”，更靠“错峰+降级+兜底”：
- 拒绝策略选 CallerRunsPolicy：当线程和队列都满时，由调用方线程执行任务，天然限流并反馈压力，避免雪崩
- 开启 allowCoreThreadTimeOut(true)：让核心线程也能在低谷期释放，节省资源；配合 keepAliveTime 设为 30～60 秒，适应波动负载
- 搭配自定义 ThreadFactory：命名规范（如 "io-pool-%d"），便于监控识别线程归属，快速定位瓶颈线程池
验证与持续调优
配置不是一劳永逸，上线后必须观测三类指标：
- 线程池指标：活跃线程数、队列长度、拒绝任务数（突增即告警）
- 系统指标：CPU 使用率是否持续 >80%、GC 频次是否上升、Full GC 是否触发
- 业务指标：任务平均延迟、超时率、下游错误率
建议用压测工具模拟 120% 日常峰值流量，观察线程池行为是否符合预期——队列是否平稳、是否触发扩容、有无拒绝、系统是否抖动。不复杂但容易忽略。
