记录的是一个 3.0 比较难搞的问题，相信不少使用过 3.0 的用户都遇到过 Master 服务中存在一些工作流或者任务流一直不停的死循环的问题，导致疯狂刷日志。不过本人到现在也没找到最关键的触发原因，只是看到一些连锁反应带来的结果……

影响因素

CPU飙高：每个工作流的运行在 Master 中都是一个线程，当这个线程一直没有结束时，是会占用CPU资源的，当服务中存在大量的线程死循环时，可想而知，服务器的资源压力有多大。

磁盘打满：循环的线程内存在日志打印，当大量的线程无时无刻在打印日志时，日志文件会迅速堆积，磁盘的大小是固定的，当磁盘使用率超过一定的阀值时，其他的程序也会因为磁盘可用空间不足而受影响。有些人设置了 Logback 等日志框架配置，限定了日志文件的总大小，但是这样也会引发日志快速覆盖问题，无法找到可用的日志。

数据库压力：每个循环里面都有相关的数据库查询操作，大量的查询会造成数据库压力短期内迅速增大，如果数据库性能不能很好的话，可能数据库就会先挂了。

异常分类

工作流异常：经过排查，大概率发现工作流 state = 4 状态的实例会刷日志

任务流异常：经过排查，大概率发现任务流 state = 6 状态的实例会刷日志

状态枚举异常：工作流、任务流一些异常状态会集中到一个异常状态集合里，监听该异常状态集合时，导致会刷日志

以上 3 种情况也分别对应代码里 3 个关键实体类：ProcessInstanceExecCacheManagerImpl、StreamTaskInstanceExecCacheManagerImpl、StateEventHandlerManager

我们见名知意可知，这 3 个实体类分别对应以上 3 种异常分类，而且都属于 Java 缓存级别管理类！

解决思路

基本的 master 服务处理工作流的一个事件流程，工作流的线程类（WorkflowExecuteRunnable）被放到缓存中，缓存的 key 是工作流实例的 ID，同时每一个工作流都有对应的事件，事件中存储工作流实例的 ID，每次执行事件时都会从缓存中获取线程类，当线程类执行失败时便重新创建一个事件加入事件队列中执行，依次往复，除非缓存中的数据被清除了，才会结束循环。具体流程如下图

1. 清空异常的工作流或任务流实例（数据库），否则重启又会重新读取问题流实例数据，又开始刷……
2. 清空以上相关的 Java 缓存（重点看异常分类的 3 个关键类），这一步是关键不重启也可解决刷日志问题，否则需要重启来替代清空缓存的操作（不优雅）

具体操作

1、进入 Master-Server 的日志目录

2、通过 grep 筛选日志中存在的问题流实例 ID（工作流实例、任务流实例）

# 工作流实例
cat dolphinscheduler-master.log |grep "ERROR" | awk -F 'WorkflowInstance-' '{print $2}'
| awk -F']' '{print $1}' | sort | uniq

# 任务流实例
cat dolphinscheduler-master.log |grep "ERROR" | awk -F 'TaskInstance-' '{print $2}'
| awk -F']' '{print $1}' | sort | uniq

Tips：这里有一点要注意，如果筛选出来有『0』的实例ID，这个经排查并没用，猜测属于系统默认ID（无视即可），而且发现规律：在日志中，如果 A 或 B 等于 0 或都等于 0，其实只要关心有正常业务值实例ID一方即可，意味着每次业务主要问题是由他（工作流实例或任务流实例）引起，如果都有正常值，那么属于任务流实例问题引起

……[WorkflowInstance-A][TaskInstance-B]……

3、分别在 Api-Server 和 Master-Server 搭建 Arthas 框架，将筛选出来的实例 ID 替换 OGNL 调用函数参数

• Arthas 快速入门见文档：快速入门 | arthas

4、删除工作流实例、任务流实例数据库数据（Api-Server 执行）

ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkProcessInstanceById("工作流实例ID")'
ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteAllSubWorkProcessByParentId("工作流实例ID")'
ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkProcessMapByParentId("工作流实例ID")'
ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processServiceImpl").deleteWorkTaskInstanceByProcessInstanceId("工作流实例ID")'

如果不想清空数据库实例，我们刚讲过主要也是因为 state = 4 引起的问题，可以通过改工作流数据库状态也是可以的

UPDATE t_ds_process_instance SET state = 5 WHERE state = 4 AND id = 工作流实例ID;

5、清空 Java 缓存（Master-Server 执行）

# 工作流实例缓存
ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("processInstanceExecCacheManagerImpl").removeByProcessInstanceId("工作流实例ID")'

# 任务流实例缓存
ognl  '@org.apache.dolphinscheduler.service.bean.SpringApplicationContext@applicationContext.getBean("streamTaskInstanceExecCacheManagerImpl").removeByTaskInstanceId("任务流实例ID")'

# 异常枚举缓存
ognl  '@org.apache.dolphinscheduler.server.master.event.StateEventHandlerManager@stateEventHandlerMap.clear()'

Tips：最后一步因为一刀切可能会误伤正常业务状态，所以最好等到只剩这些异常业务的时候再执行，也可进一步做一些定位异常业务的工作流实例ID进行精准清空（后续更新……）

附加

• ​​​​​​Arthas - Can not read arthas version from: https://arthas.aliyun.com/api/latest_version
• Arthas - Unable to open socket file: target process not responding or HotSpot VM not loaded

• 近期在跟社区的沟通中，3.1.9 和 3.2.0 版本都有涉及过该 BUG 的代码修复，使得该问题已经得到解决，感兴趣可以了解最新版本