IO密集型任务线程数应按公式“CPU核心数×(1+平均等待时间/平均计算时间)”计算，如8核、计算10ms、IO等待90ms时为80；经验法为“CPU核数÷(1−阻塞系数)”，如4核、阻塞系数0.9时为40；需设上限（通常50～200）、配合适有界队列与CallerRunsPolicy拒绝策略，并隔离业务线程池。
IO 密集型任务的线程数不能靠拍脑袋或统一乘 2 来定，关键在于理解“线程等待时 CPU 是空闲的”这一事实，目标是让 CPU 尽可能不闲置。
看阻塞占比，用公式算出理论值
更准确的做法是估算单个任务中 CPU 计算时间与 IO 等待时间的比例。通用公式为：
核心线程数 ≈ CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)
例如：服务器有 8 核，每个请求平均计算耗时 10ms，数据库查询等 IO 等待平均 90ms，则理论值 ≈ 8 × (1 + 90/10) = 80。这个数字比简单“8×2=16”更贴合实际负载。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
如果难以精确测量，可用经验替代：阻塞系数（IO 时间占总耗时比例）为 0.8～0.95 时，线程数可设为 CPU 核数 ÷ (1 − 阻塞系数)。如 4 核、阻塞系数 0.9 → 4 ÷ 0.1 = 40。
设上限，避免资源失控
公式结果只是理论参考，必须结合硬件约束做截断：
- 每个线程默认占用约 1MB 栈空间，总线程数 × 1MB 不能超过可用堆外内存
- 生产环境通常将最大线程数限制在 50～200 区间，防止上下文切换反噬性能
- 若使用数据库连接池（如 HikariCP），线程数不宜远超连接池大小，否则大量线程卡在获取连接上
配好队列和拒绝策略，别让线程数失效
线程数再合理，如果队列和拒绝策略没配对，照样会出问题：
- 选 有界队列（如 ArrayBlockingQueue），容量建议设为 100～500，配合最大线程数使用，防止任务无限堆积
- 拒绝策略优先选 CallerRunsPolicy 或自定义策略，避免突发流量直接抛异常；AbortPolicy 在关键链路中风险较高
- keepAliveTime 建议设为 60 秒以上，给非核心线程足够时间回收，减少抖动
单独隔离，不混用容器线程池
Web 应用常见误区是复用 Tomcat 的线程池处理业务异步逻辑。正确做法是：
- HTTP 请求处理走容器线程池（如 Tomcat maxThreads）
- 发短信、写日志、调第三方 API 等 IO 操作，走独立配置的业务线程池
- 不同 IO 类型（如 DB、Redis、HTTP Client）甚至可进一步拆分为多个线程池，便于监控和限流
