关键在于匹配任务特性做轻量调度：纯计算型设CPU核数+1；含IO型按公式CPU×(1+IO等待/CPU计算)估算；用有界队列+CallerRunsPolicy反压；剥离阻塞点并强制超时；动态扩缩容适配流量。
直接用线程池处理海量短请求，关键不在“堆线程”，而在让每个线程真正忙起来、不空转、不卡死。核心是匹配任务特性做轻量调度，避免资源错配导致 CPU 空转或内存积压。
按请求特征定线程池规模
短请求通常耗时低（毫秒级）、无强状态依赖，但并发量极大。此时线程数不能拍脑袋设：
- 纯计算型短请求（如 JSON 解析、简单规则判断）：设为 CPU 核数 + 1 即可。多开线程只会加剧上下文切换，反拖慢吞吐。
- 含轻量 IO 的短请求（如查本地缓存、调用 Redis、发 HTTP 短连接）：按公式粗估——CPU 数 × (1 + 平均 IO 等待时间 / 平均 CPU 计算时间)。实测中常落在 CPU 数的 2–4 倍区间。
- 拒绝盲目复用 CPU 核心数：比如 32 核机器，若单请求平均耗时 5ms（其中 4ms 在等网络），实际合理线程数可能接近 32 × (1 + 4/1) = 160，而非 32 或 64。
用有界队列+主动拒绝代替“无限缓冲”
LinkedBlockingQueue 默认无界，短请求洪峰一来，任务全塞进内存，OOM 风险极高。必须切断失控链路：
- 选 ArrayBlockingQueue，显式限定容量（如 200–500），容量根据平均 QPS × 0.5s 吞吐预估；
- 拒绝策略不用默认的 AbortPolicy（抛异常打断调用方），改用 CallerRunsPolicy：当队列满、线程达上限时，由业务线程自己同步执行一个任务。这会自然反压上游，逼客户端降速，比丢任务或崩溃更可控；
- 配合监控指标（如 rejectCount、queueSize），一旦拒绝率 > 0.5%，说明当前配置已到临界，需扩容或限流。
剥离阻塞点，释放线程周转率
短请求本该快进快出，但一个同步 DB 查询或未设超时的 HTTP 调用，就能让整个线程卡住几十毫秒——线程池再大也白搭：
- 所有外部调用强制加 超时控制（connect/read timeout ≤ 200ms）；
- 能异步的全异步：Redis 用 Lettuce（Netty 驱动）、HTTP 用 WebClient 或 OkHttp 的 callback 模式，避免线程挂起；
- 本地缓存查不到时，不要同步回源加载，改用 CacheLoader + 异步刷新，主线程只返回旧值或空值，后台悄悄更新。
动态适配流量峰谷，不靠静态配置硬扛
促销秒杀和日常流量差 10 倍，固定线程池必然失衡。可行做法：
- 用 ScheduledThreadPoolExecutor 每 30 秒采集一次活跃线程数、队列长度、平均响应时间；
- 当连续 3 次采样显示 活跃线程 ≥ 90% 且队列长度 > 容量 70%，自动上调核心线程数（每次 +2，上限不超过最大线程数）；
- 空闲 5 分钟后逐步回收，避免长期占用资源；
- 线上验证过：某电商商品详情页线程池在大促期间自动从 64 扩到 112，QPS 提升 35%，而平均延迟下降 12%。
