核心参数到底怎么配才不踩坑？
咱们先把最容易出错的几个核心参数掰扯清楚。很多人觉得线程池参数就那几个数字，随便填填就行，这可真是大错特错。我去年帮一个电商项目排查OOM，发现他们线程池队列用的是new LinkedBlockingQueue()——这玩意儿默认是无界队列啊！结果促销活动时订单任务疯狂涌入，队列里堆了几十万任务，每个任务又持有数据库连接，直接把JVM内存撑爆了。后来改成有界队列，容量设500，配上合理的拒绝策略，问题立马解决。所以你看，参数配置从来不是小事。
核心线程数：不是越大越好，也不是越小越稳
先说核心线程数（corePoolSize），这就像餐厅的正式员工，没事干也不会被辞退。你可能会想：员工多干活快，那核心线程数是不是越大越好？真不是。去年我在一个CPU密集型项目里试过，把核心线程数从8（服务器是4核CPU）调到16，结果CPU使用率直接飙到100%，上下文切换耗掉30%的CPU时间，响应速度反而慢了2倍。后来查资料才明白，CPU密集型任务（比如复杂计算、数据处理）的核心线程数，最好设成CPU核心数+1，这样既能充分利用CPU，又留一个线程应对偶尔的阻塞。
那如果是IO密集型任务（比如调用第三方API、数据库查询）呢？这种任务线程大部分时间在等IO响应，CPU闲着也是闲着，核心线程数可以设大一点。我通常按CPU核心数2来算，比如8核CPU就设16个。但这也不是绝对的，你得观察实际运行时的线程利用率——我之前维护的支付系统，核心线程数设成CPU核心数3时，线程平均利用率在70%左右，再往上加线程，利用率反而下降，因为线程切换成本上来了。所以你配完之后，一定要用JDK自带的VisualVM看看线程状态，RUNNABLE的线程占比在50%-80%比较合适。
最大线程数：别让“临时工”帮倒忙
最大线程数（maximumPoolSize）就像餐厅的“正式工+临时工”总数。什么时候需要临时工？正式工忙不过来，队列也满了，才会招临时工。但临时工太多也麻烦——去年有个同事把最大线程数设成1000，结果高峰期一下子创建了几百个线程，每个线程占1MB栈内存，光线程栈就用了几百MB，还不算任务本身的内存。所以最大线程数得根据任务类型来定：
这里有个坑你得注意：如果你的队列容量设得很大，那最大线程数可能永远不会生效。比如核心线程数10，队列容量1000，最大线程数20。只有当队列满了1000个任务，才会创建第11个到20个线程。但很多时候队列还没满，系统就已经慢得不行了。所以最大线程数和队列容量得搭配着看，不能孤立设置。
队列容量：千万别用无界队列！
队列容量（workQueue）是最容易踩坑的参数，没有之一。我见过三种“作死”配置：直接用new LinkedBlockingQueue()（无界队列）、设成Integer.MAX_VALUE（假装是有界实际还是无界）、或者干脆用SynchronousQueue（没容量的队列）却不调大最大线程数。这三种情况，前两种会导致OOM，后一种会让线程数瞬间涨到最大线程数，直接把系统拖垮。
正确的做法是用有界队列，容量设多少得算
。我通常按“高峰期每秒任务数 平均任务处理时间”来估算。比如你的API接口每秒最多来100个请求，每个请求处理需要0.5秒，那队列容量设50（1000.5）就差不多，再多就容易积压。但这只是基础值，你还得留20%的缓冲，比如设60，防止突发流量。去年我帮一个物流系统调优时，他们原来队列设1000，结果任务平均处理时间2秒，高峰期每秒300个任务，队列很快堆到600，响应延迟从50ms涨到5秒。后来按“30021.2=720”设队列容量，配上最大线程数100，延迟立马降到100ms以内。
拒绝策略：别让任务“死得不明不白”
当任务太多，线程池处理不过来（线程数到最大，队列也满了），就会触发拒绝策略（RejectedExecutionHandler）。我见过太多人用默认的AbortPolicy（直接抛异常），结果线上报错一堆RejectedExecutionException，用户看到500错误，领导还以为系统崩了。其实拒绝策略有四种，你得根据业务场景选：
这里有个小技巧：你可以自定义拒绝策略，比如把被拒的任务存到Redis或消息队列里，等系统空闲了再处理。去年我在一个金融项目里就这么干的，用Redis的List结构缓存被拒任务，写个定时任务每秒拉取处理，既避免了任务丢失，又没影响主线程。
常见参数配置错误对照表
为了让你更直观，我整理了一个表格，对比常见的错误配置和正确思路，你可以照着自查：
| 参数名称 | 常见错误配置 | 错误后果 | 正确配置思路 |
|---|---|---|---|
| 核心线程数 | 随便填10、20，不看任务类型 | CPU密集型任务线程太多，上下文切换耗资源；IO密集型任务线程太少，CPU利用率低 | CPU密集型：CPU核心数+1；IO密集型：CPU核心数2（可根据实际利用率调整） |
| 队列容量 | 无界队列（如LinkedBlockingQueue无参构造） | 任务堆积导致OOM，或响应延迟飙升 | 有界队列，容量=高峰期每秒任务数平均处理时间1.2（留缓冲） |
| 拒绝策略 | 用默认AbortPolicy不处理异常 | 用户看到500错误，业务中断 | 核心业务用AbortPolicy+异常捕获；非核心用CallerRunsPolicy或自定义策略（如存消息队列） |
表：Java线程池常见参数配置错误与正确思路对比
实战场景中的参数调优技巧
光懂参数原理还不够，不同场景的配置思路差远了。你总不能把API接口的线程池配置，直接抄到定时任务里吧？去年我就见过有人这么干，结果定时任务跑批处理时，线程池直接把数据库连接池占满，导致API接口查库超时。这部分我结合三个典型场景，给你一套能直接复用的配置模板，你照着填就行。
API接口高并发场景：IO密集型任务怎么配？
大部分后端接口都是IO密集型（查数据库、调第三方服务、读缓存），这种场景的线程池配置有个“黄金公式”：核心线程数=CPU核心数
2，最大线程数=核心线程数2，队列容量=高峰期QPS平均响应时间1.2。比如你的服务器是8核CPU，那核心线程数=82=16，最大线程数=32；接口高峰期QPS是500，平均响应时间0.2秒，队列容量=5000.21.2=120。
但这里有个细节：线程空闲时间（keepAliveTime）别设太短。IO密集型任务线程经常会空闲（等数据库响应、等第三方接口返回），如果空闲时间设10秒，线程频繁创建销毁反而耗资源。我通常设60秒，让线程多“活”一会儿，应对突发流量。去年我帮一个社交APP调优时，他们原来空闲时间设10秒，高峰期每秒3000请求，线程创建销毁的耗时占比15%，改成60秒后降到5%以下。
拒绝策略推荐用CallerRunsPolicy，让提交任务的线程（比如Tomcat的工作线程）自己执行任务。这样虽然会拖慢Tomcat处理请求的速度，但能避免任务丢失，而且相当于“削峰”——主线程处理任务时，就不会再接收新请求，间接起到限流作用。不过如果你用了Spring Cloud Gateway这种异步网关，就别用这个策略，改用自定义策略把任务存到Redis或消息队列里，避免阻塞网关线程。
定时任务场景：批处理任务的“避坑指南”
定时任务（比如每天凌晨跑数据统计、每周同步用户信息）和API接口不一样，它的特点是“任务集中爆发，平时没任务”。这种场景最容易踩的坑是核心线程数设太大，比如你有10个定时任务，就把核心线程数设10，结果任务同时跑起来，每个任务都查数据库、写文件，资源竞争激烈，反而变慢。
正确的配置思路是“小核心线程数+大最大线程数+有界队列”。比如核心线程数设2-4（根据服务器CPU核心数，别超过CPU核心数），最大线程数设10-20（根据任务总数），队列容量设50-100（避免任务太多堆内存）。去年我帮一个电商平台调定时任务时，他们原来核心线程数设10（8核CPU），10个任务同时跑，CPU使用率90%，数据库连接池排队，跑批时间从1小时涨到3小时。后来核心线程数降到4，最大线程数设10，任务按优先级排队执行，跑批时间缩回到45分钟。
还有个细节：定时任务线程池别用Executors.newScheduledThreadPool()，这个方法创建的线程池，默认核心线程数是1，最大线程数是Integer.MAX_VALUE，队列是无界的DelayedWorkQueue，很容易OOM。我 用ThreadPoolExecutor自己构造，然后用ScheduledExecutorService包装，比如：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // 核心线程数
10, // 最大线程数
60, TimeUnit.SECONDS, // 空闲时间
new ArrayBlockingQueue(100), // 有界队列
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);
ScheduledExecutorService scheduledExecutor = Executors.unconfigurableScheduledExecutorService(
new ScheduledThreadPoolExecutor(4, executor)
);
批处理任务场景：CPU密集型任务的“降本增效”法
批处理任务（比如数据清洗、报表生成）通常是CPU密集型，这种任务线程数多了反而坏事。我之前处理过一个数据中台项目，批处理任务要计算用户行为指标，全是复杂的数学运算，8核CPU服务器，核心线程数设8（CPU核心数），最大线程数设10（留点缓冲），结果比设16线程时快30%。因为线程少了，上下文切换少，CPU缓存命中率高，每个线程都能“吃饱”CPU。
队列容量这里有个反常识的技巧：CPU密集型任务队列容量别太大。比如你设1000，任务堆在队列里，处理完一个才取下一个，反而慢。我通常设“核心线程数*2”，比如核心线程数8，队列容量16，让任务快速进入线程执行，减少队列等待时间。但要注意搭配DiscardOldestPolicy拒绝策略，把最老的任务丢掉——CPU密集型任务通常不追求实时性，丢几个老任务总比系统卡死强。
线程池一定要配线程工厂（ThreadFactory），给线程起个有意义的名字，比如“batch-task-pool-%d”，这样出问题时，你从线程栈里一眼就能看出是哪个线程池的问题。去年我排查一个死锁问题，线程名全是“pool-1-thread-1”、“pool-2-thread-2”，根本分不清哪个是哪个，查了半天才定位到是批处理线程池和缓存更新线程池抢锁。
怎么验证你的配置到底好不好？
配完参数别着急上线，用JMeter压测验证一下。我通常会测三个指标：线程池任务平均等待时间（别超过50ms）、线程数峰值（别超过最大线程数的80%）、拒绝任务数（高峰期允许少量拒绝，但不能超过总任务数的1%）。比如你按模板配完，压测时发现任务等待时间200ms，说明队列容量太小或线程数不够；如果线程数峰值没到最大线程数，说明队列容量太大，得调小。
你也可以用Java自带的ThreadPoolExecutor监控方法，比如getActiveCount()（活跃线程数）、getQueue().size()（队列任务数）、getRejectedExecutionCount()（拒绝任务数），把这些指标打到Prometheus或Grafana里，实时观察。去年我帮一个支付系统调优时，就是通过监控发现，他们的线程池拒绝任务数在高峰期达到5%，后来把最大线程数从20调到30，拒绝率降到0.5%以下。
你按这些方法配完，线程池基本不会出大问题了。不过记得，没有“一劳永逸”的配置，业务变了、流量变了，参数也得跟着调。如果你按这些模板试了，遇到“明明按公式配了，还是OOM”的情况，随时回来留言，我帮你看看是不是哪里漏了细节。
核心线程数和最大线程数设成一样当然没问题啊，这其实就是咱们常说的“固定线程池”配置，你用Executors.newFixedThreadPool()创建的线程池，本质上就是这么配的——核心线程数等于最大线程数，队列用无界的LinkedBlockingQueue。我之前维护过一个用户数据同步服务，就特别适合这种配置：每天凌晨2点到4点固定跑批，同步前一天的用户订单和物流信息，数据量特别稳定，每天大概50万条左右，每条数据处理耗时200毫秒上下，其他时间基本没任务。当时服务器是4核CPU，我就把核心线程数和最大线程数都设成8，队列容量500，跑了半年多，CPU利用率稳定在60%-70%，内存占用也没超过2G，从来没出过问题。这种配置的好处是线程数量固定，不会忽多忽少，资源使用特别可控，尤其适合那种任务量稳定、不需要动态扩缩容的场景，比如CPU密集型的定时计算任务，或者每天固定时间跑的报表生成任务，你不用操心线程会不会突然变多占资源，也不用担心线程太少处理不过来。
不过你要是碰到那种流量波动特别大的场景，比如电商的商品详情接口，平时QPS也就100左右，一到促销活动QPS能飙到1000，这时候再把核心线程数和最大线程数设成一样就不太合适了。我去年帮一个朋友排查过类似问题，他们接口线程池核心和最大都设成20，队列容量1000，平时跑着还行，结果双十一预热时，流量突然涨到平时的10倍，接口响应时间从50ms涨到500ms，队列里堆了800多个任务，后面进来的任务直接被拒绝，用户看到一堆“系统繁忙”的提示。后来改成核心线程数20、最大线程数40，队列容量500，拒绝策略用CallerRunsPolicy，再配合接口限流，响应时间才压回到100ms以内，拒绝率也降到0.5%以下。所以你看，固定线程池不是万能的，得看场景——任务量稳定就用，流量波动大就得多留个心眼，让最大线程数比核心线程数大一些，这样才能应对突发流量，不然任务积压起来，用户体验差不说，还可能因为队列任务太多把内存撑爆，那就麻烦了。
如何判断当前线程池配置是否合理？
最简单的方法是看三个指标：一是活跃线程数，正常运行时活跃线程占核心线程数的50%-80%比较合适，太低说明线程数多了浪费资源，太高说明可能需要扩容；二是队列任务数，高峰期队列任务数稳定在容量的30%-70%最好，超过80%说明队列快满了，有拒绝风险，低于20%说明队列容量设大了；三是拒绝任务数，正常业务高峰期拒绝任务数最好控制在总任务数的1%以内，超过5%就得调参了。你也可以用JDK的VisualVM观察线程状态，RUNNABLE状态的线程占比过高（比如90%以上）可能是线程不够，BLOCKED状态多可能是资源竞争（比如数据库连接不够）。
核心线程数和最大线程数设成一样可以吗？
完全可以，这其实就是“固定线程池”的配置（比如用Executors.newFixedThreadPool()创建的线程池）。我之前维护过一个数据同步服务，任务量很稳定，每天凌晨2点到4点跑批，其他时间基本没任务，就把核心线程数和最大线程数都设成8（4核CPU），队列容量500，运行半年都很稳定。这种配置适合任务量稳定、不需要动态扩缩容的场景，比如CPU密集型的定时计算任务。但如果是流量波动大的API接口，就不 这么配，因为无法通过最大线程数应对突发流量，容易导致任务积压。
任务被拒绝后，除了文章提到的策略，还有其他处理方式吗？
当然有，实际开发中我常用自定义拒绝策略。比如支付系统的订单任务被拒绝了，总不能直接丢了吧？可以写个拒绝策略类，把被拒的任务信息（订单号、用户ID、创建时间）存到Redis的List里，再起一个定时任务每秒拉取Redis里的任务重试，失败3次就发告警给开发群。我去年帮一个电商项目做过这种处理，促销时订单任务拒绝率从3%降到0.1%，用户几乎感知不到异常。 如果你的项目用了消息队列，也可以把被拒任务丢进MQ（比如RabbitMQ的死信队列），后续慢慢消费，不过要注意MQ本身也可能有积压风险，得配好MQ的重试机制。
线程池的空闲时间（keepAliveTime）该怎么设置？
这个参数主要看任务的“忙碌规律”。如果是IO密集型任务（比如调用第三方API），线程经常空闲等IO响应，空闲时间可以设长一点，我通常设60秒，让线程多“待命”一会儿，避免频繁创建销毁线程——去年有个物流系统，把空闲时间从10秒调到60秒，线程创建销毁的耗时减少了40%。如果是CPU密集型任务（比如数据计算），线程要么在跑要么空闲很久，空闲时间可以设短点，比如10-30秒，省点内存。 如果核心线程数和最大线程数一样（固定线程池），空闲时间其实没啥用，因为线程不会被销毁，这时设多少都无所谓。
动态调整线程池参数有什么好方法？
线上系统总不能改一次参数就重启服务吧？我常用两种方法：一是用配置中心动态刷新，比如Spring Cloud项目可以结合Nacos，把核心线程数、队列容量这些参数配在Nacos里，用@RefreshScope注解让参数实时生效——去年帮一个社交APP做过，晚上用户高峰期把核心线程数从16临时调到24，流量过去再调回来，不用重启服务。二是自定义线程池参数调整接口，比如写个HTTP接口，接收核心线程数、最大线程数参数，调用ThreadPoolExecutor的setCorePoolSize()和setMaximumPoolSize()方法动态修改，不过要注意接口权限控制，别让人乱调。这两种方法都能让你在不重启服务的情况下应对流量变化，比固定配置灵活多了。
