系统中大量使用线程池,有必要对线程池进行监控。 可以监控如下指标: 可以检测到正在执行的线程数。 可以检测任务队列堆积任务数。 可以检测活动线程数。 可以检测最大线程数。 ? 具体如下: queue.size:获取线程池任务队列数量。 taskCount:线程池需要执行的任务数量。 completedTaskCount:线程池在运行过程中已完成的任务数量。 largestPoolSize:线程池曾经创建过的最大线程数量。通过这个数据可以知道线程池是否满过。如等于线程池的最大大小,则表示线程池曾经满了。 getPoolSize:线程池的线程数量。 通过扩展线程池进行监控,通过继承线程池并重写线程池的beforeExecute,afterExecute和terminated方法,我们可以在任务执行前,执行后和线程池关闭前干一些事情。 如监控任务的平均执行时间,最大执行时间和最小执行时间等。 这几个方法在线程池里是空方法。
线程池配置核心业务线程池和非核心业务线程池 核心业务的线程不够用 可以停掉非核心业务占用的线程 application.properties #线程池配置 gmall.pool.coreSize=8 java.util.concurrent.TimeUnit; /** * @author: xiepanpan * @Date: 2020/2/27 * @Description: 配置当前系统的线程池信息 WuliuService 2s 700ms new Thread(()->{ log.info("查配送信息"); }).start(); //5、 //高并发系统的优化 //1、加缓存 //2、开异步 return null; } } 监控线程池: package com.xiepanpan.gmall.portal.controller java.util.concurrent.ThreadPoolExecutor; /** * @author: xiepanpan * @Date: 2020/2/28 * @Description: 监控线程池
最近我们组杨青同学遇到一个使用线程池不当的问题:异步处理的线程池线程将主线程hang住了,分析代码发现是线程池的拒绝策略设置得不合理,设置为CallerRunsPolicy。 从这个问题中,我们学到了两点: 线程池的使用,需要充分分析业务场景后作出选择,必要的情况下需要自定义线程池; 线程池的运行状况,也需要监控 关于线程池的监控,我参考了《Java编程的艺术》中提供的思路实现的 DEFAULT_QUEUE_SIZE; @Setter private int poolSize = DEFAULT_POOL_SIZE; /** * 用于周期性监控线程池的运行状态 ;(2)拒绝策略是将任务丢弃,但是需要记录错误日志;(3)使用一个调度线程池对业务线程池进行监控。 在查看监控日志的时候,看到下图所示的监控日志: ?
背景 业务使用线程池的时候,出现了问题,影响线上业务,由于没有线程池监控,导致问题难以发现和排查。于是需要这么一个线程池监控组件,用来监控线程池执行状态,任务执行状态等。 = 被监控的线程池1, 提交任务数+1 [ThreadPoolMonitor_0] INFO PoolMonitorTask - 线程池名称 = 被监控的线程池1, 活跃线程数峰值 = 0, 队列任务数峰值 - 线程池名称 = 被监控的线程池1, 任务排队时间 = 1, 任务执行时间 = 86 [ThreadPoolMonitor_0] INFO PoolMonitorTask - 线程池名称 = 被监控的线程池 「监控参数」 poolName :线程池名称。必须为每个线程池创建不同的名称,否则会抛出异常。可以将其作为监控平台的 id,通过名称找到对应的监控数据。 monitorConfig :监控配置参数。 , 提交任务数+1 [被监控的线程池2_0] INFO MonitoredThreadPoolExecutor - 线程池名称 = 被监控的线程池2, 任务排队时间 = 0, 任务执行时间 = 0 [被监控的线程池
包括:创建线程池,销毁线程池,添加线程或任务等等 线程池创建线程来执行,而Worker执行完之后,就去队列中取未分配的task,调用task的run方法。 ,可以执行多个任务 提高响应速度 不需要频繁的创建线程,如果有线程可以直接用,不会出现系统僵死 提高线程的可管理性 线程池可以约束系统最多只能由多少个线程,不会因为线程过多而死机 线程池的核心思想 线程复用 //第二次向线程池提交任务,此时线程池创建新线程 pool.submit(task); //第三次向线程池提交任务,此时线程池创建新线程 pool.submit(task ); //第四次向线程池提交任务,超出线程池固定数量,此时线程池复用之前的线程 // pool.shutdown(); 在等待任务执行完毕之后关闭线程池 Runnable{ @Override public void run() { for(int i=0;i<5;i++){ System.out.println
背景 在开发中,我们经常要使用Executors类创建线程池来执行大量的任务,使用线程池的并发特性提高系统的吞吐量。 但是,线程池使用不当也会使服务器资源枯竭,导致异常情况的发生,比如固定线程池的阻塞队列任务数量过多、缓存线程池创建的线程过多导致内存溢出、系统假死等问题。 因此,我们需要一种简单的监控方案来监控线程池的使用情况,比如完成任务数量、未完成任务数量、线程大小等信息。 ExecutorsUtil工具类 以下是我们开发的一个线程池工具类,该工具类扩展ThreadPoolExecutor实现了线程池监控功能,能实时将线程池使用信息打印到日志中,方便我们进行问题排查、系统调优 统计任务耗时、初始线程数、核心线程数、正在执行的任务数量、已完成任务数量、任务总数、队列里缓存的任务数量、池中存在的最大线程数、最大允许的线程数、线程空闲时间、线程池是否关闭、线程池是否终止信息 监控到的记录如下
在使用slf4j的MDC做日志跟踪的时候,会因为MDC不能跨线程导致跟踪失败,此外,为了监控线上服务器的运行状态,也很有必要对线程池的运行情况进行监控。 下面是一个带有线程池监控且兼容MDC的线程池,建议使用! /** * A SLF4J MDC-compatible {@link ThreadPoolExecutor}. MDC.setContextMap(previous); } } }; } } 参考 如何在线程池中使用 线程池的五种状态 Java线程池监控小结
e.printStackTrace(); } })); } Thread.sleep(3000); // out => 等待线程 threadPoolExecutor.getQueue().size()); } 获取到堆积大小了,就可以通过打印日志的形式进行输出,也可以通过micrometer + prometheus + grafana进行完整的监控 ,可参考 通过micrometer实时监控线程池的各项指标 拓展: ThreadPoolExecutor支持其他数量监控,例如: ?
考虑到之前用micrometer + prometheus + grafana搭建过监控体系,于是考虑使用micrometer做一次主动的线程池度量数据采集,最终可以相对实时地展示在grafana的面板中 2、提供两个方法,分别使用线程池实例模拟短时间耗时的任务和长时间耗时的任务。 3、提供一个方法用于清空线程池实例中的任务队列。 F:thread_pool_queue_size,Legend:-线程池积压任务数。 最终效果 多调用几次例子中提供的几个接口,就能得到一个监控线程池呈现的图表: ? 小结 针对线程池ThreadPoolExecutor的各项数据进行监控,有利于及时发现使用线程池的接口的异常,如果想要快速恢复,最有效的途径是:清空线程池中任务队列中积压的任务。 像HTTP客户端的连接池如Apache-Http-Client或者OkHttp等的监控,可以用类似的方式实现,数据收集的时候可能由于加锁等原因会有少量的性能损耗,不过这些都是可以忽略的,如果真的怕有性能影响
,最左边3位表示线程池状态。 /注:简单的说,3个二进制位可以表示从0-7的8个不同的数值(第1处) 4 private static final int COUNT_BITS = Integer.SIZE - 3; 5 = (1 << COUNT_BITS) - 1; 8 9 // runState is stored in the high-order bits 10 //用左边3位,实现5种线程池状态 返回false 的可能如下: * 1.线程池没有处于RUNNING状态 * 2.线程工程创建新的任务线程失败 * @param firstTask 外部启动线程池时需要构造的第一个线程 = rs) //如果线程池的状态发生变化则重试(第5处) continue retry; // else CAS failed due
所以需要通过线程池协调多个线程,并实现类似主次线程隔离、定时执行、周期执行等任务。线程池的作用包括: 利用线程池管理并复用线程、控制最大并发数等。 实现任务线程队列缓存策略和拒绝机制。 隔离线程环境。比如,交易服务和搜索服务在同一台服务器上,分别开启两个线程池,交易线程的资源消耗明显要大;因此,通过配置独立的线程池,将较慢的交易服务与搜索服务隔开,避免个服务线程互相影响。 在了解线程池的基本作用后,我们学习一下线程池是如何创建线程的。 如果待执行的线程数大于此值,需要借助第5个参数的帮助。缓存在队列中。如果maximumPoolSize 与corePoolSize 相等,即是固定大小线程池。 Executors核心方法有5个: Executors.newWorkStealingPool:JDK8 引入,创建持有足够线程的线程池,支持给定的并行堵,并通过使用对个队列减少竞争,此构造方法中把cpu
文章目录 一、线程池作用 二、线程池种类 三、线程池工作机制 四、线程池任务调度源码解析 一、线程池作用 ---- 线程池作用 : ① 避免创建线程 : 避免每次使用线程时 , 都需要 创建线程对象 ; ---- 线程池种类 : ① newCachedThreadPool : 可缓存线程池 , 如果 线程池线程个数已满 , 回收空闲线程 , 如果没有空闲线程 , 此时会创建新线程 ; ② newFixedThreadPool 后到的后执行 ) , LIFO 后入先出 ( 后到的先执行 ) ; 三、线程池工作机制 ---- 线程池线程相关概念: 线程数 : 线程池的 有 最大线程数 MaxSzie , 核心线程数 CoreSize , 非核心线程数就是 MaxSize - CoreSize ; 示例 : 最大线程数 ( MaxSize ) 是 8 个 , 有 3 个核心线程 ( CoreSize ) , 5 个非核心线程 , 任务拒绝后 , 处理善后 ; 四、线程池任务调度源码解析 ---- 在 AsyncTask.java 中 , 在静态代码块中 , 自己 自定义创建了线程池 , 没有使用上述四种线程池 ; 创建线程池时传入的参数
文章目录 一、线程池简介 二、线程池初始化方法简介 三、线程池使用示例 一、线程池简介 ---- 线程池一般是实现了 ExecutorService 接口的类 , 一般使用 ThreadPoolExecutor 是 自己配置的线程池 , 没有使用 Java 默认提供的四种线程池 , Java 提供的四种线程池是 可缓存线程池 , 定长线程池 , 定长周期任务线程池 , 单线程线程池 ; THREAD_POOL_EXECUTOR 3 , 非核心线程数 5 ; 线程池任务队列 : 当启动一个线程池后 , 线程池会不停地从该任务队列中取出任务执行 , 启动核心线程 : 如果当前核心线程没有满 , 小于 3 个 , 那么创建核心线程执行该任务 , 启动非核心线程 : 如果当前核心线程已经有 3 个 , 但是 非核心线程没有满 , 小于 5 个 , 那么会创建非核心线程 , 执行该任务 ; 执行者 Executor 执行任务处理 : 如果核心线程数 有 3 个 , 非核心线程数有 5 个 , 最大线程数已满 ; 如果用户再提交任务给线程池 , 就会 将任务放入线程池任务队列中排队 ; 如果此时任务队列也满了 , 此时就会
如果设置为0,所有线程都不能进入,要一直等资源池放通。 maximumCount 表示最大允许几个线程进入资源池。 Release() 表示退出信号量并返回前一个计数。这个计数指的是资源池还可以进入多少个线程。 ,资源池还有多少线程可以进入?" 而 Semaphor 类,会对此进行严格监控,如果对应调用数量不一致,会出现异常。 这就好像笔筒里面的笔,没有监控,使用这使用完毕后,都应该将笔放进去。如果原先有10支笔,每次使用不放进去,或者将别的地方的笔放进去,那么最后数量就不是10了。 ?
concurrent.futures --- 启动并行任务 — Python 3.7.13 文档concurrent.futures 模块提供异步执行可调用对象高层接口异步执行可以由 ThreadPoolExecutor 使用线程或由 **Executor**ThreadPoolExecutor 线程池```pythonimport concurrent.futuresimport urllib.requestURLS = ['http statement to ensure threads are cleaned up promptlywith concurrent.futures.ThreadPoolExecutor(max_workers=5) exc)) else: print('%r page is %d bytes' % (url, len(data)))```ProcessPoolExecutor 进程池使用进程池来实现异步执行调用 任何向池提交更多工作的尝试, initializer 都将引发一个异常,当前所有等待的工作都会引发一个 BrokenProcessPool。
在我进行 Java 编程实践当中,特别是高性能编程时,线程池是无法逾越的高山。在最近攀登高山的路途上,我又双叒叕掌握了一些优雅地使用线程池的技巧。 通常我会将异步任务丢给线程池去处理,不怎么会额外处理异步任务执行中报错。 一般来说,任务执行报错,会终止当前的线程,这样线程池会创建新的线程执行下一个任务,当然是在需要创建线程和可以创建新线程的前提下。 所以不得不让我开始研究如何处理线程池中异步任务的异常了。 以下是我的研究报告,诚邀各位共赏。 就我的水平而言,总计发现 5 种常见的异常处理方式。 将自定义 ThreadFactory 应用于线程池: 在创建线程池时,通过 Executors 或 ThreadPoolExecutor 使用自定义的 ThreadFactory。
线程池同时被quartz和非quartz使用,才需要使用此类 5. ThreadPoolTaskExecutor :最常使用,推荐。 1、定义线程池 在Spring Boot主类中定义一个线程池,public Executor taskExecutor() 方法用于自定义自己的线程池,线程池前缀”taskExecutor-”。 60秒:超过了核心线程数之外的线程,在空闲时间到达之后会被销毁 线程池名的前缀:设置好了之后可以方便我们定位处理任务所在的线程池 线程池对拒绝任务的处理策略:此处采用了CallerRunsPolicy策略 -- id指定线程池产生线程名称的前缀 --> <task:executor id="xmlExecutor" pool-size="<em>5</em>-25" ‘rejection-policy’: 对拒绝的任务处理策略 5. ‘keep-alive’ : 线程保活时间(单位秒) 四、异常处理 上面也提到:在调用方法时,可能出现方法中抛出异常的情况。
像这种,提前创建好线程,需要的时候直接使用,我们称之为线程池。这种本质上就是一个生产消费模型。 线程池实现 //ThreadPool.hpp #pragma once #include<iostream> #include<unistd.h> #include<string> #include< include<functional> #include"Thread.hpp" using namespace threadModel; static const int gdefaultnum=5; lg.Enable(SCREEN_TYPE);}while(0) #define EnableFile() do{lg.Enable(FILE_TYPE);}while(0) }; 携带日志的线程池设计 Task>(); tp->Init(); tp->Start(); int cnt=10; while (cnt) { // 不断地向线程池推送任务
int corePoolSize = 2; /* 核心线程池的最大线程数 */ int maxPoolSize = 4; /* 线程最大空闲时间 */ 不推荐使用Executors的静态方法创建线程池 !!! 第2节 ForkJoinPool ---- ForkJoin线程池处理无返回值任务。 初始化数组用时:1847192纳秒, 初始化数组总和:493016 线程池计算用时:4220889纳秒, 线程池执行结果:493016 ? 第3节 两种线程池的比较 ---- ThreadPoolExecutor——适用于IO密集型任务 1.HTTP 2.RPC 3.DB 4.Redis 5.MQ 6.ZK ForkJoinPool——
之前写过一篇 Java 线程池的使用介绍文章《线程池全面解析》,全面介绍了什么是线程池、线程池核心类、线程池工作流程、线程池分类、拒绝策略、及如何提交与关闭线程池等。 但在实际开发过程中,在线程池使用过程中可能会遇到各方面的故障,如线程池阻塞,无法提交新任务等。 如果你想监控某一个线程池的执行状态,线程池执行类 ThreadPoolExecutor 也给出了相关的 API, 能实时获取线程池的当前活动线程数、正在排队中的线程数、已经执行完成的线程数、总线程数等。 总线程数 = 排队线程数 + 活动线程数 + 执行完成的线程数。 下面给出一个线程池使用示例,及教你获取线程池状态。 ,最后输出: 当前排队线程数:0 当前活动线程数:0 执行完成线程数:100000 总线程数(排队线程数 + 活动线程数 + 执行完成线程数):100000 这样,你了解了这些 API 的使用方法,你想监控线程池的状态就非常方便了