大家好,这篇文章我们来聊下动态线程池开源项目(DynamicTp)的通知告警模块。目前项目提供以下通知告警功能,每一个通知项都可以独立配置是否开启、告警阈值、告警间隔时间、平台等,具体代码请看core模块notify包。

1.核心参数变更通知

2.线程池活跃度告警

3.队列容量告警

4.拒绝策略告警

5.任务执行超时告警

6.任务排队超时告警


DynamicTp项目地址

目前700star,感谢你的star,欢迎pr,业务之余一起给开源贡献一份力量

gitee地址https://gitee.com/yanhom/dynamic-tp

github地址https://github.com/lyh200/dynamic-tp


系列文章

美团动态线程池实践思路,开源了

动态线程池框架(DynamicTp),监控及源码解析篇

动态线程池(DynamicTp),动态调整Tomcat、Jetty、Undertow线程池参数篇


线程池解读

上篇文章里大概讲到了JUC线程池的执行流程,我们这里再仔细回顾下,上图是JUC下线程池ThreadPoolExecutor类的继承体系。

顶级接口Executor提供了一种方式,解耦任务的提交和执行,只定义了一个execute(Runnable command)方法用来提交任务,至于具体任务怎么执行则交给他的实现者去自定义实现。

ExecutorService接口继承Executor,且扩展了生命周期管理的方法、返回Futrue的方法、批量提交任务的方法

void shutdown();
List<Runnable> shutdownNow();
boolean isShutdown();
boolean isTerminated();
boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException; <T> Future<T> submit(Callable<T> task);
<T> Future<T> submit(Runnable task, T result);
Future<?> submit(Runnable task); <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks,long timeout, TimeUnit unit) throws InterruptedException;
<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;
<T> T invokeAny(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;

AbstractExecutorService抽象类继承ExecutorService接口,对ExecutorService相关方法提供了默认实现,用RunnableFuture的实现类FutureTask包装Runnable任务,交给execute()方法执行,然后可以从该FutureTask阻塞获取执行结果,并且对批量任务的提交做了编排

protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
return new FutureTask<T>(runnable, value);
} public Future<?> submit(Runnable task) {
if (task == null) throw new NullPointerException();
RunnableFuture<Void> ftask = newTaskFor(task, null);
execute(ftask);
return ftask;
}

ThreadPoolExecutor继承AbstractExecutorService,采用池化思想管理一定数量的线程来调度执行提交的任务,且定义了一套线程池的生命周期状态,用一个ctl变量来同时保存当前池状态(高3位)和当前池线程数(低29位)。看过源码的小伙伴会发现,ThreadPoolExecutor类里的方法大量有同时需要获取或更新池状态和池当前线程数的场景,放一个原子变量里,可以很好的保证数据的一致性以及代码的简洁性。

  // 用此变量保存当前池状态(高3位)和当前线程数(低29位)
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int CAPACITY = (1 << COUNT_BITS) - 1; // runState is stored in the high-order bits
// 可以接受新任务提交,也会处理任务队列中的任务
// 结果:111跟29个0:111 00000000000000000000000000000
private static final int RUNNING = -1 << COUNT_BITS; // 不接受新任务提交,但会处理任务队列中的任务
// 结果:000 00000000000000000000000000000
private static final int SHUTDOWN = 0 << COUNT_BITS; // 不接受新任务,不执行队列中的任务,且会中断正在执行的任务
// 结果:001 00000000000000000000000000000
private static final int STOP = 1 << COUNT_BITS; // 任务队列为空,workerCount = 0,线程池的状态在转换为TIDYING状态时,会执行钩子方法terminated()
// 结果:010 00000000000000000000000000000
private static final int TIDYING = 2 << COUNT_BITS; // 调用terminated()钩子方法后进入TERMINATED状态
// 结果:010 00000000000000000000000000000
private static final int TERMINATED = 3 << COUNT_BITS; // Packing and unpacking ctl
// 低29位变为0,得到了线程池的状态
private static int runStateOf(int c) { return c & ~CAPACITY; }
// 高3位变为为0,得到了线程池中的线程数
private static int workerCountOf(int c) { return c & CAPACITY; }
private static int ctlOf(int rs, int wc) { return rs | wc; }

核心入口execute()方法执行逻辑如下:

public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}

可以总结出如下主要执行流程,当然看上述代码会有一些异常分支判断,可以自己顺理加到下述执行流程里

1.判断线程池的状态,如果不是RUNNING状态,直接执行拒绝策略

2.如果当前线程数 < 核心线程池,则新建一个线程来处理提交的任务

3.如果当前线程数 > 核心线程数且任务队列没满,则将任务放入任务队列等待执行

4.如果 核心线程池 < 当前线程池数 < 最大线程数,且任务队列已满,则创建新的线程执行提交的任务

5.如果当前线程数 > 最大线程数,且队列已满,则拒绝该任务

addWorker()方法逻辑

private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (;;) {
int c = ctl.get();
// 获取当前池状态
int rs = runStateOf(c); // 1.判断如果线程池状态 > SHUTDOWN,直接返回false,否则2
// 2.如果线程池状态 = SHUTDOWN,并且firstTask不为null则直接返回false,因为SHUTDOWN状态的线程池不能在接受新任务,否则3
// 3.如果线程池状态 = SHUTDOWN,并且firstTask == null,此时如果任务队列为空,则直接返回false
if (rs >= SHUTDOWN &&
! (rs == SHUTDOWN &&
firstTask == null &&
! workQueue.isEmpty()))
return false; for (;;) {
int wc = workerCountOf(c);
// 1.如果当前线程池线程数大于等于CAPACITY(理论上的最大值5亿),则返回fasle
// 2.如果创建核心线程情况下当前池线程数 >= corePoolSize,则返回false
// 3.如果创建非核心线程情况下当前池线程数 >= maximumPoolSize,则返回false
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false;
// cas 增加当前池线程数量,成功则退出循环
if (compareAndIncrementWorkerCount(c))
break retry;
c = ctl.get(); // Re-read ctl
// cas 增加当前池线程数量失败(多线程并发),则重新获取ctl,计算出当前线程池状态,如果不等于上述计算的状态rs,则说明线程池状态发生了改变,需要跳到外层循环重新进行状态判断
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
} boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
// 至此说明线程池状态校验通过,且增加池线程数量成功,则创建一个Worker线程来执行任务
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
final ReentrantLock mainLock = this.mainLock;
// 访问worker set时需要获取mainLock
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
int rs = runStateOf(ctl.get()); // 1.当前池状态 < SHUTDOWN,也就是RUNNING状态,如果已经started,抛出异常
// 2.当前池状态 = SHUTDOWN,且firstTask == null,需要处理任务队列中的任务,如果已经started,抛出异常
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && firstTask == null)) {
if (t.isAlive()) // precheck that t is startable
throw new IllegalThreadStateException();
// 添加到workers集合中
workers.add(w);
int s = workers.size();
// 判断更新历史最大线程数量
if (s > largestPoolSize)
largestPoolSize = s;
workerAdded = true;
}
} finally {
mainLock.unlock();
}
if (workerAdded) {
// 启动新建线程
t.start();
workerStarted = true;
}
}
} finally {
if (! workerStarted)
// 启动失败,workerCount--,workers里移除该worker
addWorkerFailed(w);
}
return workerStarted;
}

线程池中的线程并不是直接用的Thread类,而是定义了一个内部工作线程Worker类,实现了AQS以及Runnable接口,然后持有一个Thread类的引用及一个firstTask(创建后第一个要执行的任务),每个Worker线程启动后会执行run()方法,该方法会调用执行外层runWorker(Worker w)方法

final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
boolean completedAbruptly = true;
try {
// 1.如果task不为空,则作为该线程的第一个任务直接执行
// 2.如果task为空,则通过getTask()方法从任务队列中获取任务执行
while (task != null || (task = getTask()) != null) {
w.lock();
// If pool is stopping, ensure thread is interrupted;
// if not, ensure thread is not interrupted. This
// requires a recheck in second case to deal with
// shutdownNow race while clearing interrupt
// 线程池状态 >= STOP,则中断线程
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt();
try {
// 实际执行任务前调用的钩子方法
beforeExecute(wt, task);
Throwable thrown = null;
try {
// 实际执行任务
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
// 任务执行后调用的钩子方法
afterExecute(task, thrown);
}
} finally {
// 任务置为null,重新获取新任务,完成数++
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
// 无任务可执行,执行worker销毁逻辑
processWorkerExit(w, completedAbruptly);
}
}

getTask()方法逻辑

private Runnable getTask() {
boolean timedOut = false; // Did the last poll() time out? for (;;) {
int c = ctl.get();
int rs = runStateOf(c); // 以下两种情况递减工作线程数量
// 1. rs >= STOP
// 2. rs == SHUTDOWN && workQueue.isEmpty()
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
} int wc = workerCountOf(c); // Are workers subject to culling?
// 允许核心线程超时 或者 当前线程数 > 核心线程数,有可能发生超时关闭
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize; // wc什么情况 > maximumPoolSize,调用setMaximumPoolSize()方法将maximumPoolSize调小了,会发生这种情况,此时需要关闭多余线程
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
} try {
// 阻塞队列获取任务
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
// 发生中断,进行重试
timedOut = false;
}
}
}

以上内容比较详细的介绍了ThreadPoolExecutor的继承体系,以及相关的核心源码,基于此,现在我们来看DynamicTp提供的告警通知能力。


核心参数变更通知

对应配置中心的监听端监听到配置变更后,封装到DtpProperties中然后交由DtpRegistry类中的refresh()方法去做配置更新,同时通知时会高亮显示有变更的字段


线程池活跃度告警

活跃度 = activeCount / maximumPoolSize

服务启动后会开启一个定时监控任务,每隔一定时间(可配置)去计算线程池的活跃度,达到配置的threshold阈值后会触发一次告警,告警间隔内多次触发不会发送告警通知


队列容量告警

容量使用率 = queueSize / queueCapacity

服务启动后会开启一个定时监控任务,每隔一定时间去计算任务队列的使用率,达到配置的threshold阈值后会触发一次告警,告警间隔内多次触发不会发送告警通知


拒绝策略告警

/**
* Do sth before reject.
* @param executor ThreadPoolExecutor instance
*/
default void beforeReject(ThreadPoolExecutor executor) {
if (executor instanceof DtpExecutor) {
DtpExecutor dtpExecutor = (DtpExecutor) executor;
dtpExecutor.incRejectCount(1);
Runnable runnable = () -> AlarmManager.doAlarm(dtpExecutor, REJECT);
AlarmManager.triggerAlarm(dtpExecutor.getThreadPoolName(), REJECT.getValue(), runnable);
}
}

线程池线程数达到配置的最大线程数,且任务队列已满,再提交任务会触发拒绝策略。DtpExecutor线程池用到的RejectedExecutionHandler是经过动态代理包装过的,在执行具体的拒绝策略之前会执行RejectedAware类beforeReject()方法,此方法会去做拒绝数量累加(总数值累加、周期值累加)。且判断如果周期累计值达到配置的阈值,则会触发一次告警通知(同时重置周期累加值为0及上次告警时间为当前时间),告警间隔内多次触发不会发送告警通知


任务队列超时告警

重写ThreadPoolExecutor的execute()方法和beforeExecute()方法,如果配置了执行超时或排队超时值,则会用DtpRunnable包装任务,同时记录任务的提交时间submitTime,beforeExecute根据当前时间和submitTime的差值就可以计算到该任务在队列中的等待时间,然后判断如果差值大于配置的queueTimeout则累加排队超时任务数量(总数值累加、周期值累加)。且判断如果周期累计值达到配置的阈值,则会触发一次告警通知(同时重置周期累加值为0及上次告警时间为当前时间),告警间隔内多次触发不会发送告警通知

@Override
public void execute(Runnable command) {
if (CollUtil.isNotEmpty(taskWrappers)) {
for (TaskWrapper t : taskWrappers) {
command = t.wrap(command);
}
} if (runTimeout > 0 || queueTimeout > 0) {
command = new DtpRunnable(command);
}
super.execute(command);
}
@Override
protected void beforeExecute(Thread t, Runnable r) {
if (!(r instanceof DtpRunnable)) {
super.beforeExecute(t, r);
return;
}
DtpRunnable runnable = (DtpRunnable) r;
long currTime = System.currentTimeMillis();
if (runTimeout > 0) {
runnable.setStartTime(currTime);
}
if (queueTimeout > 0) {
long waitTime = currTime - runnable.getSubmitTime();
if (waitTime > queueTimeout) {
queueTimeoutCount.incrementAndGet();
Runnable alarmTask = () -> AlarmManager.doAlarm(this, QUEUE_TIMEOUT);
AlarmManager.triggerAlarm(this.getThreadPoolName(), QUEUE_TIMEOUT.getValue(), alarmTask);
}
} super.beforeExecute(t, r);
}


任务执行超时告警

重写ThreadPoolExecutor的afterExecute()方法,根据当前时间和beforeExecute()中设置的startTime的差值即可算出任务的实际执行时间,然后判断如果差值大于配置的runTimeout则累加排队超时任务数量(总数值累加、周期值累加)。且判断如果周期累计值达到配置的阈值,则会触发一次告警通知(同时重置周期累加值为0及上次告警时间为当前时间),告警间隔内多次触发不会发送告警通知

@Override
protected void afterExecute(Runnable r, Throwable t) { if (runTimeout > 0) {
DtpRunnable runnable = (DtpRunnable) r;
long runTime = System.currentTimeMillis() - runnable.getStartTime();
if (runTime > runTimeout) {
runTimeoutCount.incrementAndGet();
Runnable alarmTask = () -> AlarmManager.doAlarm(this, RUN_TIMEOUT);
AlarmManager.triggerAlarm(this.getThreadPoolName(), RUN_TIMEOUT.getValue(), alarmTask);
}
} super.afterExecute(r, t);
}


告警通知相关配置项

如果想使用通知告警功能,配置文件必须要配置platforms字段,且可以配置多个平台,如钉钉、企微等;notifyItems配置具体告警项,包括阈值、平台、告警间隔等。

spring:
dynamic:
tp:
# 省略其他项
platforms: # 通知平台
- platform: wechat
urlKey: 38a98-0c5c3b649c
receivers: test
- platform: ding
urlKey: f80db3e801d593604f4a08dcd6a
secret: SECb5444a6f375d5b9d21
receivers: 17811511815
executors: # 动态线程池配置,都有默认值,采用默认值的可以不配置该项,减少配置量
- threadPoolName: dtpExecutor1
executorType: common # 线程池类型common、eager:适用于io密集型
corePoolSize: 2
maximumPoolSize: 4
queueCapacity: 200
queueType: VariableLinkedBlockingQueue # 任务队列,查看源码QueueTypeEnum枚举类
rejectedHandlerType: CallerRunsPolicy # 拒绝策略,查看RejectedTypeEnum枚举类
keepAliveTime: 50
allowCoreThreadTimeOut: false
threadNamePrefix: dtp1 # 线程名前缀
waitForTasksToCompleteOnShutdown: false # 参考spring线程池设计
awaitTerminationSeconds: 5 # 单位(s)
preStartAllCoreThreads: false # 是否预热核心线程,默认false
runTimeout: 200 # 任务执行超时阈值,目前只做告警用,单位(ms)
queueTimeout: 100 # 任务在队列等待超时阈值,目前只做告警用,单位(ms)
taskWrapperNames: ["ttl"] # 任务包装器名称,集成TaskWrapper接口
notifyItems: # 报警项,不配置自动会按默认值配置(变更通知、容量报警、活性报警、拒绝报警、任务超时报警)
- type: capacity # 报警项类型,查看源码 NotifyTypeEnum枚举类
threshold: 80 # 报警阈值
platforms: [ding,wechat] # 可选配置,不配置默认拿上层platforms配置的所以平台
interval: 120 # 报警间隔(单位:s)
- type: change
- type: liveness
threshold: 80
interval: 120
- type: reject
threshold: 1
interval: 160
- type: run_timeout
threshold: 1
interval: 120
- type: queue_timeout
threshold: 1
interval: 140

总结

本文开头介绍了线程池ThreadPoolExecutor的继承体系,核心流程的源码解读。然后介绍了DynamicTp提供的以上6种告警通知能力,希望通过监控+告警可以让我们及时感知到我们业务线程池的执行负载情况,第一时间做出调整,防止事故的发生。


联系我

对项目有什么想法或者建议,可以加我微信交流,或者创建issues,一起完善项目

公众号:CodeFox

微信:yanhom1314

美团动态线程池实践思路开源项目(DynamicTp),线程池源码解析及通知告警篇的更多相关文章

  1. Scala 深入浅出实战经典 第65讲:Scala中隐式转换内幕揭秘、最佳实践及其在Spark中的应用源码解析

    王家林亲授<DT大数据梦工厂>大数据实战视频 Scala 深入浅出实战经典(1-87讲)完整视频.PPT.代码下载:百度云盘:http://pan.baidu.com/s/1c0noOt6 ...

  2. 一个Python开源项目-哈勃沙箱源码剖析(下)

    前言 在上一篇中,我们讲解了哈勃沙箱的技术点,详细分析了静态检测和动态检测的流程.本篇接着对动态检测的关键技术点进行分析,包括strace,sysdig,volatility.volatility的介 ...

  3. vs2008编译QT开源项目--太阳神三国杀源码分析(三) 皮肤

    太阳神三国杀的界面很绚丽,界面上按钮的图标,鼠标移入移出时图标的变化,日志和聊天Widget的边框和半透明等效果,既可以通过代码来控制,也可以使用皮肤文件qss进行控制.下面我们分析一下三国杀的qss ...

  4. airbnb 开源reAir 工具 用法及源码解析(一)

    reAir 有批量复制与增量复制功能 今天我们先来看看批量复制功能 批量复制使用方式: cd reair ./gradlew shadowjar -p main -x test # 如果是本地tabl ...

  5. elementUi源码解析(1)--项目结构篇

    因为在忙其他事情好久没有更新iview的源码,也是因为后面的一些组件有点复杂在考虑用什么方式把复杂的功能逻辑简单的展示出来,还没想到方法,突然想到element的组件基本也差不多,内部功能的逻辑也差不 ...

  6. Android 开源项目源码解析(第二期)

    Android 开源项目源码解析(第二期) 阅读目录 android-Ultra-Pull-To-Refresh 源码解析 DynamicLoadApk 源码解析 NineOldAnimations ...

  7. Python优秀开源项目Rich源码解析

    这篇文章对优秀的开源项目Rich的源码进行解析,OMG,盘他.为什么建议阅读源码,有两个原因,第一,单纯学语言很难在实践中灵活应用,通过阅读源码可以看到每个知识点的运用场景,印象会更深,以后写代码的时 ...

  8. 【原】Android热更新开源项目Tinker源码解析系列之一:Dex热更新

    [原]Android热更新开源项目Tinker源码解析系列之一:Dex热更新 Tinker是微信的第一个开源项目,主要用于安卓应用bug的热修复和功能的迭代. Tinker github地址:http ...

  9. 【原】Android热更新开源项目Tinker源码解析系列之二:资源文件热更新

    上一篇文章介绍了Dex文件的热更新流程,本文将会分析Tinker中对资源文件的热更新流程. 同Dex,资源文件的热更新同样包括三个部分:资源补丁生成,资源补丁合成及资源补丁加载. 本系列将从以下三个方 ...

随机推荐

  1. gitee中项目到运行操作,包括:打包、热部署、数据库操作

    使用的工具:window10.IDEA 2018.2.3 .navicat110_premium.Git-2.23 1.idea导入gitee代码 复制项目地址 选择git工具 粘贴地址,点击clon ...

  2. Semantic Text Similarity

    stop word是指像the,is ,are等等方向的词 stemming意思就是将形式化为一样的形式,比如lists,listed,list都可以化为list形式.

  3. Mybatis执行流程浅析

    从三个主要的对象SqlSessionFactoryBuilder->SqlSessionFactory->SqlSession说起 inputStream = Resources.getR ...

  4. 使用 Docker 部署 LNMP 并搭建 wordpress

    准备 系统版本:CentOS Linux release 7.4.1708 (Core)   内核版本:3.10.0-693.el7.x86_64    IP:192.168.31.43    可访问 ...

  5. NoSQL:Redis缓存、雪崩、击穿、穿透

    Redis介绍 Redis(Remote Dictionary Server ),即远程字典服务,是一个开源的使用ANSI C语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库 ...

  6. 寻路算法之A*算法详解

    前言 在实际开发中我们会经常用到寻路算法,例如MMOARPG游戏魔兽中,里面的人物行走为了模仿真实人物行走的体验,会选择最近路线达到目的地,期间会避开高山或者湖水,绕过箱子或者树林,直到走到你所选定的 ...

  7. 如何在 Java 中实现二叉搜索树

    二叉搜索树 二叉搜索树结合了无序链表插入便捷和有序数组二分查找快速的特点,较为高效地实现了有序符号表.下图显示了二叉搜索树的结构特点(图片来自<算法第四版>): 可以看到每个父节点下都可以 ...

  8. python+pytest接口自动化(12)-自动化用例编写思路 (使用pytest编写一个测试脚本)

    经过之前的学习铺垫,我们尝试着利用pytest框架编写一条接口自动化测试用例,来厘清接口自动化用例编写的思路. 我们在百度搜索天气查询,会出现如下图所示结果: 接下来,我们以该天气查询接口为例,编写接 ...

  9. XML技术的作用?

    XML技术用于数据存储.信息配置.数据交换三方面. 可以将数据存储在XML中,通过节点.元素内容.属性标示数据内容及关系. 可以使用XML很方便的做信息配置,软件的各种配置参数和对象关系都存贮在XML ...

  10. @RequestMapping 注解?

    该注解是用来映射一个URL到一个类或一个特定的方处理法上.