多线程配置的核心不是把线程数拉高，而是先判断任务属于CPU密集型还是IO密集型，再对应调整线程数、队列容量和拒绝策略，线上服务才能避免越配越卡。
多线程配置怎么设置才合理？先看这两类任务
多线程配置想一次到位基本不可能，但第一步必须分清任务类型，同样一个8核服务器，跑图片压缩和跑接口转发,合理的线程数可能差出好几倍。
CPU密集型任务：线程数跟着核数走，别多加
图片压缩、视频转码、加密解密、正则匹配,这类任务大部分时间都在消耗CPU时钟周期。
线程开多了，操作系统反而要把时间花在上下文切换上，每个线程切来切去,CPU真正干活的比例会下降。
行业共识认为,CPU密集任务的线程数最优区间在核数到核数加一之间。
比如8核机器,线程池可以这样配：
int cores = Runtime.getRuntime().availableProcessors();
ThreadPoolExecutor pool = new ThreadPoolExecutor(
cores + 1,
cores + 1,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(200),
new ThreadPoolExecutor.CallerRunsPolicy()
);
线上压测时再看CPU使用率，如果核数线程下CPU使用率长时间接近满载，说明任务确实吃计算资源，加线程也换不来更多吞吐，如果CPU使用率只有60%左右且队列经常积压，那多半任务里有IO等待,需要重新归类。
IO密集型任务：等待时间越长，越要用线程数换并行度
接口转发、数据库查询、文件读写、远程调用,这类任务花在等待上的时间比计算多。
等待IO时CPU是空闲的,这时多开一些线程能把空闲的计算时间利用起来。
一个常用的估算起点是：
线程数 = 核数 × 2
但这不是固定答案，更准确的办法是估算阻塞系数,也就是一个任务里等待时间占总耗时的比例。
比如一个接口平均耗时100毫秒，其中数据库查询等待80毫秒，阻塞系数就是0.8,按公式：
线程数 = 核数 / (1 - 阻塞系数)
8核机器算下来就是40个线程，这个数字和核数乘2的估算差别很大,但更贴近实际。
IO密集场景下，队列容量要比CPU密集场景大一些,避免瞬时流量直接把线程池打满。
线程池参数对比：固定线程池和缓存线程池哪个更适合线上服务
固定线程池和缓存线程池最大的区别不在于线程数,而在于队列策略和线程回收策略。
核心参数逐个看：corePoolSize、maxPoolSize、workQueue
| 参数 | 作用 | 设错的常见后果 | 推荐策略 |
|---|---|---|---|
| corePoolSize | 常驻线程数 | 过小吞吐上不去，过大空闲浪费 | CPU密集=核数+1；IO密集先按核数×2再压测 |
| maxPoolSize | 最大线程数 | 设太大上下文切换频繁 | 高于core但不要过分，IO密集可再上调 |
| workQueue | 任务排队队列 | 无界队列可能内存溢出 | 有界队列，容量根据单任务耗时估算 |
| keepAliveTime | 非核心线程空闲存活时间 | 过短频繁创建销毁 | 30到60秒起步，突发流量场景可放宽 |
固定线程池通常把corePoolSize和maxPoolSize设成一样，搭配无界队列，这种配置在任务量稳定时没问题，一旦流量翻倍，队列会无限堆积,最终拖垮内存。
缓存线程池把corePoolSize设成0，maxPoolSize设成接近无限大，搭配SynchronousQueue，任务来了就创建线程，空闲60秒回收，它适合大量短小异步任务,不适合有界资源下的长时间调用。
线上服务多数情况下应该使用自定义ThreadPoolExecutor，而不是直接使用Executors工厂方法，这样队列类型、线程数、拒绝策略都能自己控制。
拒绝策略：队列满了之后怎么办
线程池拒绝策略有四种：
- AbortPolicy：抛异常,通常并不友好。
- CallerRunsPolicy：由提交任务的线程自己执行,适合关键业务降级。
- DiscardPolicy：直接丢弃，适合日志、埋点等可损失场景。
- DiscardOldestPolicy：丢弃最旧任务,适合时效性强的消息队列消费。
业内专家指出，线上线程池事故里，无界队列导致的内存溢出占比相当高，把队列设成有界，再配合CallerRunsPolicy降级,是多数生产环境里更稳妥的选择。
服务器多线程配置场景：从Nginx到Tomcat别再照搬模板
不同服务器软件的多线程配置关键词完全不同，Nginx配的是worker进程和连接数，Tomcat配的是请求处理线程,数据库连接池配的是连接数。
Nginx多线程配置：worker_processes设置成auto通常够用
Nginx配置文件的路径一般是 /etc/nginx/nginx.conf。
worker_processes auto;
events {
worker_connections 1024;
}
worker_processes auto 会让Nginx自动匹配CPU核数,多数情况下比手动指定数字更合理。
Nginx的worker进程是单线程事件循环模型，一个worker可以同时处理大量连接，不是传统意义上每个连接一个线程,所以worker_connections的数值比worker_processes更影响并发能力。
Tomcat多线程配置：maxThreads不是越大越好
Tomcat的线程池配置在 conf/server.xml 里：
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="200"
acceptCount="100" />
maxThreads决定同时处理请求的最大线程数，设到400、800，看起来能接更多请求，但每个线程都会占用内存和CPU调度资源,线程切换的成本在并发量上去后会非常明显。
更实际的做法是观察Tomcat监控里的当前线程数和请求处理时间，如果请求处理平均耗时长，先把后端响应时间降下来，再加线程数,否则只是让慢请求堆积得更快。
数据库连接池多线程配置：HikariCP的maximumPoolSize怎么估
数据库连接池是另一类常见多线程配置，连接数设太小，线程等连接；设太大,数据库端又扛不住。
HikariCP官方给出的估算方法是：
connections = ((core_count 2) + effective_spindle_count)
其中effective_spindle_count是磁盘数,现在多数SSD环境可以按1到2估。
比如8核云服务器跑Spring Boot应用，最大连接池数量可以先设10到20，再用压测调整，不要一上来就设100,大多数MySQL实例扛不住这么多同时活跃连接。
多线程配置多少钱？云服务器选型与线程数成本账
多线程配置多少钱，这个问题通常不是问软件配置本身,而是问支撑高并发需要买什么规格的云主机。
云服务器的价格主要和vCPU核数、内存大小、地域、带宽有关，多线程配置能跑得多快,首先看vCPU数量。
多数云厂商的按量计费实例中，4核8G的单价会明显高于2核4G，但并发处理能力提升不是简单翻倍,因为线程调度和内存带宽也会成为瓶颈。
如果只是跑Nginx反向代理或Redis缓存，2核4G的入门配置通常能顶住中等流量，如果是Java后端服务带数据库连接池和大量远程调用，建议至少4核8G起步，否则线程池刚开起来,内存就被JVM和连接池吃掉了相当一部分。
还有一种成本误区是只盯CPU核数，忽略内存带宽，多线程任务频繁读写内存时，双通道内存和单通道内存的性能差异会比核数更明显，选购云主机时，核数和内存比例最好保持1比2到1比4之间,避免高核心低内存的配置。
北京服务器多线程配置：地域差异会不会改变参数
线程数公式和队列策略不会因为地域改变，但部署在北京机房的服务器有一个实际影响,就是跨地域调用延迟。
如果业务用户集中在北方，北京服务器多线程配置确实能降低网络往返时间，相比把服务放在华南或西部地域，北京到北方用户的网络延迟更短,同一个接口的IO等待时间也会更低。
这意味着阻塞系数变小，同样核数下需要的线程数可以适当减少，比如原本按核数乘3配置的IO密集型线程池，在北京机房低延迟环境下，可能核数乘2.5就够,反而节省了内存和调度开销。
但这只适用于用户集中北方的业务，如果用户分布全国，单地域部署无论如何都会有一部分用户走跨省链路，这时线程池的队列容量和超时参数要放大,给慢请求留出排队空间。
北京地域的云服务器同规格价格多数情况下比中西部地域高一些，如果预算紧张，可以用CDN或边缘节点弥补,不用把所有服务器都堆在北京。
多线程配置常见问题快问快答
多线程配置中的队列满了会怎样？
队列满了之后，线程池会触发拒绝策略，如果配置的是CallerRunsPolicy，提交任务的线程会自己执行这个任务；如果是AbortPolicy，会抛出RejectedExecutionException；如果是DiscardPolicy，任务会静默丢弃，没有配置拒绝策略且使用无界队列时，队列不会满,但内存可能先被打满。
多线程配置需要监控哪些指标？
至少要看四个指标：当前活跃线程数、队列中等待任务数、任务平均等待时间、任务平均执行时间，活跃线程数长期接近maxPoolSize且队列持续积压，说明处理能力不足，队列经常为空但线程数很高，说明线程数配置过剩,可以下调corePoolSize节省资源。
多线程配置中的keepAliveTime设置多长合适？
keepAliveTime只对超过corePoolSize的那部分非核心线程生效，如果业务流量有明显的波峰波谷，比如午间和晚间高峰，可以设置60到120秒，让非核心线程在峰值过后还能存活一段时间，避免频繁创建，如果流量平稳，设置30到60秒就够，corePoolSize以内的线程不会因为keepAliveTime到期而被回收,除非调用了allowCoreThreadTimeOut。