先抛出一个问题,程序开发真的是线程越多效率越高吗?多线程是我们程序开发中必不可少的手段,线程就像“孙悟空”开启了分身术一样,每个分身都在“打妖怪”,那是不是分身越多,“打妖怪”的效率就越高?
文章目录
- 一、前言
- 二、演示实例
- 三、执行结果
- 四、结论分析
一、前言
其实,线程的数量并不是越多越好,每个线程都需要系统分配一定的资源,如内存和CPU时间。每个线程都有其栈内存,线程数量过多可能导致内存不足,甚至可能影响系统的稳定性。线程的管理和使用需要根据具体的应用场景和需求来决定,通常,线程数量应与可用的CPU核心数相匹配,或者稍微多一些,以充分利用多核处理器的能力。如果线程数量超过了CPU核心数,线程间的上下文切换会变得频繁,可能会导致性能下降。
一般情况下,根据业务的需求及服务器的配置,调整最优的线程池参数来进行线程调优,提升程序的执行效率。说线程池调优之前,先说下线程池的4个重要参数,分别是:corePoolSize(核心线程数)、maximumPoolSize(最大线程数)、workQueue(队列容量)、keepAliveTime(非核心回收超时时间)。
corePoolSize:是线程池中保持活动状态的线程的最小数量,即使这些线程在空闲时也不会被终止。
maximumPoolSize:是线程池能够容纳的最大线程数量,限制线程池中线程的最大数量,防止过多线程的创建,避免资源耗尽和系统过载。
workQueue:是一个阻塞队列,用于存储待执行的任务。
keepAliveTime:线程存活时间,是线程池中多余线程(即除过corePoolSize之外的线程)在空闲时保持活动的最大时间。如果线程在此时间内没有被使用,则会被终止。
以下通过一个demo来演示下线程池中实际参与工作的线程数!
二、演示实例
我们初始化的参数分别是corePoolSize=10、maximumPoolSize=30、workQueue=50,然后依次模拟5、10、15、45、60、65、75、80、81的任务数,下面的演示模拟的代码:
java"> public static void main(String[] args) {// 模拟任务数int taskCount = 75;// 使用AtomicInteger线程安全的计数器,支持在多线程环境中安全地增减值而不需要使用锁AtomicInteger integer = new AtomicInteger();// 定义一个时间区间集合,存储各个任务执行到时的耗时(单位:毫秒)情况List<Long> diffList = new ArrayList<>();// 初始化线程池,核心参数如下ThreadPoolExecutor executor = new ThreadPoolExecutor(10, // 核心线程数30, // 最大线程数5, // 非核心回收超时时间TimeUnit.SECONDS, // 超时时间单位new ArrayBlockingQueue<>(50)); // 任务队列// 记录当前时间戳long start = System.currentTimeMillis();// 模拟程序任务for (int i = 0; i < taskCount; i++) {Thread thread = new Thread(() -> {try {// 模拟执行耗时1秒Thread.sleep(1000);// 自增步进1并返回新值int j = integer.addAndGet(1);// 当前任务耗时记录long l = System.currentTimeMillis() - start;System.out.println("已执行" + j + "个任务,耗时" + l + "ms");// 把耗时记录存储到集合中diffList.add(l);} catch (InterruptedException e) {e.printStackTrace();}});// 把线程放到线程池中try {executor.execute(thread);} catch (Exception e) {e.printStackTrace();}}// 验证程序执行结束,并记录结束时间戳long end = 0;while (executor.getCompletedTaskCount() < taskCount) {end = System.currentTimeMillis();}System.out.println("总任务数:"+taskCount);/*** 1.把集合中所有时间区间的值都除以1000,这样的话,集合中的值就只会出现整型的1、2、3...,用于标识任务属于哪个批次(刚好1秒一个批次)* 2.然后把集合聚合分组整理成HashMap,方便我们统计各个批次的数量* 3.然后打印出来*/Map<Long, List<Long>> collect = diffList.stream().map(i -> i / 1000).collect(Collectors.groupingBy(i -> i.longValue()));for (Long l : collect.keySet()) {System.out.println("第【"+l+"】批次,工作线程数:"+collect.get(l).size());}System.out.println("任务总耗时:" + (end - start) + "ms");}
三、执行结果
为了方便对比查看,我把每次的执行结果都贴到一起了,如下:
总任务数:5
第【1】批次,工作线程数:5
任务总耗时:1074ms
-----------------------------------------
总任务数:10
第【1】批次,工作线程数:10
任务总耗时:1069ms
-----------------------------------------
总任务数:15
第【1】批次,工作线程数:10
第【2】批次,工作线程数:5
任务总耗时:2068ms
-----------------------------------------
总任务数:45
第【1】批次,工作线程数:10
第【2】批次,工作线程数:10
第【3】批次,工作线程数:10
第【4】批次,工作线程数:10
第【5】批次,工作线程数:5
任务总耗时:5117ms
-----------------------------------------
总任务数:60
第【1】批次,工作线程数:10
第【2】批次,工作线程数:10
第【3】批次,工作线程数:10
第【4】批次,工作线程数:10
第【5】批次,工作线程数:10
第【6】批次,工作线程数:10
任务总耗时:6151ms
-----------------------------------------
总任务数:65
第【1】批次,工作线程数:15
第【2】批次,工作线程数:15
第【3】批次,工作线程数:15
第【4】批次,工作线程数:15
第【5】批次,工作线程数:5
任务总耗时:5128ms
-----------------------------------------
总任务数:75
第【1】批次,工作线程数:25
第【2】批次,工作线程数:25
第【3】批次,工作线程数:25
任务总耗时:3079ms
-----------------------------------------
总任务数:80
第【1】批次,工作线程数:30
第【2】批次,工作线程数:30
第【3】批次,工作线程数:20
任务总耗时:3079ms
-----------------------------------------
总任务数:81
java.util.concurrent.RejectedExecutionException: Task Thread[Thread-80,5,main] rejected from java.util.concurrent.ThreadPoolExecutor@6b143ee9[Running, pool size = 30, active threads = 30, queued tasks = 50, completed tasks = 0]
-----------------------------------------
四、结论分析
根据上述结果分析,可以得到如下结论:
数量关系 | 工作线程数 | task示例 | |
---|---|---|---|
场景1 | taskCount <= corePoolSize | taskCount | 5、10 |
场景2 | corePoolSize < taskCount <= corePoolSize+workQueue | corePoolSize | 15、45、60 |
场景3 | corePoolSize+workQueue < taskCount <= maximumPoolSize+workQueue | taskCount-workQueue | 65、75、80 |
场景4 | taskCount > maximumPoolSize+workQueue | 小于的部分正常执行,大于的部分会拒绝策略,在线程池中抛出异常 | 81 |
字段说明 | corePoolSize(核心线程数)、maximumPoolSize(最大线程数)、workQueue(队列容量)、taskCount(任务数) | ||
所以,不一定任务数量少就耗时少,也不一定任务数量多就耗时长,因为不同任务下线程池分配的工作线程数是不一样的。合理地调配资源和参数,在充分利用服务器资源的同时,可以达到程序执行的最优状态!