测试JAVA线程池核心数满了后什么时候开始创建新的线程

只要是Java面试,基本上线程池是没跑了。但是有个点总是卡在那里,不是很清楚,就是核心线程池数满了,没到最大线程数的时候。到底什么时候开始建线程呢,本文就从代码结果层面来测试一下。
首先,我们来创建了一个线程池,设置核心数5个,最大线程数10个,任务队列10个,alive时间是2s,每个任务就是随机的sleep一会,主要用来占用时间。
创建完线程后,每隔一秒钟,获取一下线程池的状态。
根据输出发现,当任务数大于5个后,active数依然没变,只要任务数为16个的时候,active才变为6,也就是说当5个核心数满了,任务队列也满了后,才开始创建新的线程。
当线程执行完任务的时候,等待设置的alive时间后,开始销毁,知道active=0。
也就是核心线程也是会被销毁的。

环境

mac,jdk8,ThreadPoolExecutor

测试代码

package com.koolearn;

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * @author POPE
 * @version 1.0
 * @date 2020/7/10 5:22 下午
 */
public class ThreadPoolTest {

    /**
     * 测试JAVA线程池 核心池满了后什么情况下创建新的线程
     * 结论:当任务来的时候,判断是否有线程,没有就创建,当大于核心线程池后,放到任务队列,队列满了后创建新的线程执行,直到线程数等于最大线程数
     * 当任务执行完后,线程会等待设置的时长后销毁,包括核心线程,都会销毁,直到active的线程数是0
     * @param args
     */
    public static void main(String[] args) {
        BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(10);
        ThreadPoolExecutor es = new ThreadPoolExecutor(5,10,2, TimeUnit.SECONDS,workQueue);

        for (int i = 0; i < 20; i++) {
            int a = i;
            es.submit(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(a*500);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            });
            String name = Thread.currentThread().getName()+"-"+i;
    
<think>好的,用户之前问过Java线程池的参数实例,现在接着问核心线程数和最大线程数怎么设定合理。我需要先回顾之前的回答,确保这次的内容连贯。之前已经详细介绍了线程池的七个参数,并给出了示例代码和执行流程。现在用户更关注这两个关键参数的设置,可能是在实际项目中遇到了性能调优的问题,或者想优化现有的线程池配置。 用户可能是开发人员,正在处理多线程任务,需要根据不同的任务类型来调整线程数。他们可能对CPU密集型和IO密集型任务的区别不太清楚,或者不知道如何具体应用这些理论到实际中。需要给出具体的建议,比如公式或经验法则,同时结合场景说明。 需要确定核心线程数和最大线程数的设置依据。根据常见的实践,CPU密集型任务通常设置为CPU核心数+1,而IO密集型则可能需要更多线程,比如2倍核心数。但用户可能想知道更详细的解释,比如为什么这样设置,或者是否有动态调整的方法。 另外,用户可能关心如何避免资源耗尽和OOM问题,所以需要提到队列的选择和拒绝策略的配合。比如,使用有界队列防止任务无限堆积,或者根据任务特性选择不同的队列类型。 还要考虑是否要介绍监控和动态调整的方法,比如Spring的ThreadPoolTaskExecutor,或者Hystrix的线程池配置,但可能超出当前问题的范围。不过可以简要提及,让用户知道有这些工具可用。 需要结构清晰,分点说明,可能包括任务类型分析、参数设置公式、注意事项、示例场景等。同时结合之前的回答,保持一致性,比如之前提到的参数设置建议,这里需要详细展开核心和最大线程数的部分。 需要验证下是否有最新的最佳实践,或者是否有不同的观点,比如是否核心线程数等于最大线程数在某些情况下更合适。比如在响应式编程或异步处理中,可能采用不同的策略。 还要注意避免过于技术化的术语,用通俗的中文解释清楚。比如解释CPU密集型任务为什么需要较少的线程,IO密集型为什么可以更多,因为线程在等待IO时可以释放CPU资源。 最后,给出一个总结性的建议,帮助用户快速决策,同时提醒他们实际测试的重要性,因为理论值可能需要根据具体环境调整。</think>在Java线程池中,核心线程数(`corePoolSize`)和最大线程数(`maximumPoolSize`)的设置直接影响系统性能和资源利用率。以下是结合不同场景的详细设定建议: --- ### 一、基础公式与原则 | 参数 | 作用 | 设置原则 | |----------------|-----------------------------------|-----------------------------------| | 核心线程数 | 长期保留的线程,处理常规任务 | **不低于最低需求**,避免频繁创建/销毁 | | 最大线程数 | 应对突发流量的临时线程 | **不高于系统承载极限**,防止资源耗尽 | --- ### 二、按任务类型划分 #### 1. **CPU密集型任务** 特点:大量计算(如算法运算、数值分析) 公式: $$ \text{核心线程数} = \text{CPU核心数} + 1 $$ $$ \text{最大线程数} = \text{核心线程数} \quad \text{或} \quad \text{核心数} \times 1.5 $$ 示例: ```java // 8核CPU处理视频转码任务 int core = Runtime.getRuntime().availableProcessors() + 1; // 9 int max = core; // 保持与核心数一致 ``` #### 2. **IO密集型任务** 特点:频繁等待(如数据库操作、网络请求) 公式: $$ \text{核心线程数} = \text{CPU核心数} \times 2 $$ $$ \text{最大线程数} = \text{核心数} \times (2 \sim 5) $$ 示例: ```java // 8核CPU处理HTTP请求 int core = Runtime.getRuntime().availableProcessors() * 2; // 16 int max = core * 3; // 48 ``` #### 3. **混合型任务** 策略: - 拆分为CPU/IO两种线程池分别处理 - 使用动态调整策略: $$ \text{最大线程数} = \frac{\text{任务总耗时}}{\text{CPU计算耗时}} \times \text{核心数} $$ --- ### 三、高级调整策略 #### 1. **利特尔法则(Little's Law)** 适用于需要控制响应时间的场景: $$ \text{线程数} = \frac{\text{平均响应时间} + \text{平均等待时间}}{\text{平均响应时间}} \times \text{CPU核心数} $$ #### 2. **动态调整(适用云原生场景)** ```java ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newCachedThreadPool(); executor.setCorePoolSize(动态值); // 根据监控指标实时调整 executor.setMaximumPoolSize(动态值); ``` #### 3. **Spring Boot实践建议** ```yaml # application.yml task: execution: pool: core-size: 8 max-size: 20 queue-capacity: 100 ``` --- ### 四、关键注意事项 1. **队列容量与线程数的平衡** - 大队列+小线程数:适合短任务、高吞吐场景 - 小队列+大线程数:适合长任务、低延迟场景 2. **避免典型误区** - ❌ 核心线程数=0:导致频繁创建/销毁线程 - ❌ 最大线程数=Integer.MAX_VALUE:引发OOM风险 - ❌ 核心线程数=最大线程数:失去应对突发流量的能力 3. **监控指标参考** | 指标 | 健康值域 | 干预措施 | |-----------------------|-------------------|-----------------------------------| | 活跃线程数 / 最大线程数 | < 80% | 正常 | | 队列使用率 | < 90% | 扩容队列或线程数 | | 拒绝任务数 | =0 | 优化拒绝策略或扩容 | --- ### 五、真实场景案例 #### 电商秒杀系统(突发流量) ```java // 16核服务器配置 int core = 16; // 基础承载能力 int max = 16 * 5; // 应对瞬时流量(80线程) BlockingQueue queue = new LinkedBlockingQueue(500); // 缓冲队列 // 配合拒绝策略:队列时返回错误提示 RejectedExecutionHandler handler = new ThreadPoolExecutor.AbortPolicy(); ``` #### 数据分析后台(稳定负载) ```java // 32核服务器处理批量计算 int core = 32 + 1 = 33; int max = 33; // 保持固定线程数 BlockingQueue queue = new ArrayBlockingQueue(1000); // 有序队列 ``` --- ### 六、验证工具推荐 1. **JVisualVM**:监控线程状态和CPU使用率 2. **Arthas**:实时查看线程池运行状态 ```bash thread -n 5 # 查看最忙的5个线程 dashboard # 监控线程池队列情况 ``` 3. **Prometheus + Grafana**:搭建可视化监控平台 --- 合理设置线程数的本质是在**资源利用率**和**系统稳定性**之间找到平衡点。建议先通过公式计算理论值,再结合压力测试(如JMeter)逐步优化,最终以实际监控数据为准动态调整。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值