ACT_RU_JOB 运行实例表全解：Activiti 作业调度与定时器排障实战

如果你在一个以 Activiti 做流程引擎的项目里待过，打开数据库大概率会看到一片ACT_前缀的表。第一次看到ACT_RU_JOB时，我以为它只是记录历史作业的日志表，直到有一次线上流程的定时器怎么都不触发，才意识到这张运行实例表承担着整个引擎的“闹钟”职责。这篇文章是 25 张表拆解系列的第 1 篇，先把第 14 张运行实例表ACT_RU_JOB讲透：它为什么存在、每个字段到底什么意思、作业是怎么被调度执行和删除的，以及排障时最值得记住的几条 SQL。

文中涉及的方法和结论，大多来自我实际排查过的生产案例，也参考了 Activiti 6.x/7.x 版本的默认表结构。不同小版本字段会有些差别，这很正常，我会把常见差异标出来，你看的时候对照自己的库结构验证一下。

1. ACT_RU_JOB 在运行实例表中的定位：专管“还没到时候”的任务

1.1 Activiti 25 张表的分类与 ACT_RU_JOB 的坐标

Activiti 的表不是漫无目的堆出来的，它们按职责分成几组。ACT_GE_是通用数据，比如资源、字节数组；ACT_RE_是流程定义和模型这类静态资源；ACT_RU_是运行时数据，包括执行实例、任务、变量、身份关系等；ACT_HI_是历史数据；ACT_ID_是用户和组信息。运行时数据里，ACT_RU_EXECUTION是执行树的核心，ACT_RU_TASK是待办任务，ACT_RU_VARIABLE是流程变量，而ACT_RU_JOB专门用来存放需要延迟执行或异步执行的作业。

很多人会把这 25 张表按“是否常用”划分，ACT_RU_JOB在早期项目里存在感很低，因为不排查定时器问题时你几乎不会主动查看它。但它属于运行实例表，意思很明确：只要表里还有作业数据，就说明有流程实例正在等待某个未来时刻，或者某个异步步骤还没跑完。作业被成功执行后，对应行会被删除，所以正常情况下这张表的行数应该维持在一个比较低的水平。

官方清单里它排在运行实例表的第 14 位，也就是你标题里看到的“运行实例表 14”。这个编号更多是表清单的排序，不代表调用顺序。真正重要的是：ACT_RU_JOB是连接 BPMN 时间等待语义和底层调度线程池的桥梁。

1.2 为什么要在运行时表里单独维护一份“待办调度”

流程引擎里经常出现这样的场景：用户完成一个任务后，流程需要等 5 分钟再执行下一步；或者开始事件配置了一个定时器，每个工作日早上 8 点发起流程；又或者某个服务任务配置了异步执行，当前事务提交后再继续跑。这些需求都有一个共同点：“不是现在立刻执行，而是未来某个时刻执行”。

如果把这些待执行的逻辑直接塞进ACT_RU_EXECUTION，那张表会变得极其拥挤，而且定时扫描整个执行树来判断“谁该到期了”非常低效。Activiti 的做法是把未来要执行的动作抽象成一条条作业记录，单独放进ACT_RU_JOB。你可以把这理解成车站的候车大厅：所有还没发车的乘客都在候车大厅排队，票上写着发车时间；到了时间，广播会通知对应车次检票。ACT_RU_JOB就是那张写着车次、时间、目的地的待发车列表，Job Executor 就是广播员。

这种设计还有一个好处：作业的调度频率、锁定机制、重试策略都可以独立于流程实例进行控制。比如多台应用服务器同时运行 Activiti，多个 Job Executor 会同时抢这张表里的作业，谁抢到锁谁执行。如果作业执行失败，还可以重试。如果这些都由执行树承担，开发和运维都会非常痛苦。

2. 字段全景：身份、锁、调度、异常四组各管什么

2.1 一张表看懂 ACT_RU_JOB 的全部字段（附版本差异）

Activiti 6.x/7.x 的ACT_RU_JOB比较完整的字段结构如下。我按常见数据库方言写类型，实际在 MySQL、Oracle、PostgreSQL 上会略有差异。

如果你用的是 Activiti 5.x，表里通常没有REPEAT_、CUSTOMVALUES_ID_、CREATE_TIME_、SCOPE_*、ELEMENT_*这些字段。Activiti 7 在某些版本里还把作业拆成了多张表，比如定时器作业、死信作业、挂起作业等，但核心字段逻辑基本沿用同一套设计。看到哪个版本就按哪个版本的元数据来，网上很多旧帖子的表结构截图已经过时，别直接照抄。

2.2 几个容易搞混的关键字段和行为

先说EXCLUSIVE_。同一流程实例关联的多个作业，如果EXCLUSIVE_=1，Job Executor 在某个时刻只会执行其中一个，避免并行执行同一流程的数据导致资源竞争。如果EXCLUSIVE_=0，这些作业可以被不同线程同时拉起来跑。默认情况下异步继续作业通常是排他的，但在一些需要并发的场景里，你会看到非排他作业。这个字段不要轻易改，想要并发控制应该从 BPMN 模型层面设计。

LOCK_OWNER_和LOCK_EXP_TIME_是集群锁机制的核心。Job Executor 会先执行一条类似“抢锁”的更新语句，把作业的LOCK_OWNER_设为自己的节点名，LOCK_EXP_TIME_设为当前时间加上锁超时时间。抢到锁的节点才算真正拿到这个作业的执行权。执行完成后立刻把作业行删除，锁也就自然释放了。如果执行到一半宕机，锁会等到LOCK_EXP_TIME_过期后由其他节点重新抢走，防止作业永久卡住。

RETRIES_表示剩余重试次数。每次执行失败，引擎会把RETRIES_减 1，把异常信息写进EXCEPTION_MSG_，如果配置了堆栈存储，还会把完整堆栈写到ACT_GE_BYTEARRAY并通过EXCEPTION_STACK_ID_关联。当RETRIES_=0时，作业不会自动再跑，而是留在表里等待人工介入。很多线上事故的根源就是这里：作业失败后没人看，累积了一大堆RETRIES_=0的僵尸作业。

DUEDATE_是作业的执行时间点。Timer 作业的到期时间就是业务上“等 X 时间”的那个时刻。Job Executor 扫描时只关心DUEDATE_ <= 当前时间且未被锁定的记录。所以数据库服务器和应用服务器的时间不一致，会直接导致定时器提前或延后触发。踩过这个坑的人应该深有体会。

2.3 作业表和周边表的外键关系

ACT_RU_JOB最频繁关联的表是ACT_RU_EXECUTION。EXECUTION_ID_指向某个执行实例，PROCESS_INSTANCE_ID_指向流程实例，而这个流程实例本质上也是执行树里的根执行实例。当流程实例被删除时，引擎通常会级联清理掉它名下的作业，但如果手工在数据库里删流程实例，就很容易留下孤儿作业。

PROC_DEF_ID_关联ACT_RE_PROCDEF，用于定位流程定义。EXCEPTION_STACK_ID_和CUSTOMVALUES_ID_都关联到ACT_GE_BYTEARRAY，一个是异常堆栈字节，一个是自定义数据字节。TENANT_ID_在多租户场景下用来隔离数据，跨租户排查时经常忘记了加这个条件。

从数据完整性的角度说，ACT_RU_JOB的很多关联字段都不是数据库外键约束，而是引擎级联维护的逻辑关系。所以你直接删ACT_RU_JOB数据时，数据库不一定报错，但引擎内存里如果有对应的实体对象，后续提交时可能因为乐观锁失败报异常。这也是为什么我一直强调：能用接口就用接口，尽量别绕过引擎操作表。

3. 作业的一生：写入、抢锁、执行、重试和删除是怎么串起来的

3.1 作业从哪来：三类来源的写入场景

第一类最常见的来源是 BPMN 中的定时器事件。比如流程走到某个用户任务，边界上挂了一个定时器事件，定义是“如果 48 小时后还没处理就自动发送提醒”。引擎在到达边界事件时生成一条TYPE_为 timer 的作业，DUEDATE_是当前时间加 48 小时。流程执行到定时中间捕获事件同理，ACT_RU_JOB里会有一条等待，只有到期后流程才能继续。

第二类是异步继续。有些服务任务或执行监听器配置了async=true，引擎不会在同一个事务里立刻执行它们，而是写入一条类型为 async-continuation 的作业。核心目的是把流程执行和业务事务解耦，避免长事务或接口调用阻塞整个流程事务的提交。这类作业通常很快就会被执行，EXCLUSIVE_值多为 1。

第三类是消息事件或服务集成产生的作业。比如调用外部系统失败后延迟重试，或者 Spring 集成场景里投递的异步消息。不同版本里TYPE_的具体取值会有差异，但你可以通过HANDLER_TYPE_查看实际处理器。理解来源很重要，否则你看到大量 job 堆积时，根本不知道它们是卡住了，还是仅仅因为业务需求就是长期等待。

3.2 Job Executor 如何扫描、加锁并执行

Activiti 的调度核心是 Job Executor。它通常是一个后台线程池，按固定间隔扫描ACT_RU_JOB，找出所有“到期且没有被锁定”的作业。扫描不是一次把整个表捞出来，而是按配置的最大获取数量来拉一批。找到候选作业后，每个工作线程会尝试对作业加锁。加锁过程大概是一句条件更新 SQL：把LOCK_OWNER_从空值改成当前节点标识，LOCK_EXP_TIME_设置成当前时间加锁超时时间，同时要求原LOCK_OWNER_为空或锁已过期。更新影响行数为 1 才表示抢锁成功。

抢锁成功后，引擎根据HANDLER_TYPE_调用对应的作业处理器，执行真正的业务逻辑。如果成功，作业行被删除。如果失败，重试次数减一，异常信息写入表。下个扫描周期，这个作业再次被拉出来重试，直到重试次数耗尽。

这里有个容易被忽视的细节：作业执行时的数据库事务边界。异步继续作业的执行通常和流程实例的推进在一个事务里，Timer 作业的执行也会更新执行实例状态。如果你在作业执行的处理器里调用外部接口，而这个外部接口很慢，锁超时时间设得太短的话，作业还没跑完锁就过期了，其他节点可能认为这个作业是无人处理的，又抢过去重复执行，导致业务重复提交。这类问题比想象中常见，尤其多节点部署时。

3.3 失败重试、死信和重复调度

重试并不是立刻马上再来一次，而是等待下一个扫描周期。扫描周期的默认值在不同版本里可能是 5 秒、10 秒或更长，和AsyncExecutor配置有关。所以失败后你看到RETRIES_从 3 变成 2，可能等了十几秒才变化，这很正常。如果你希望失败后尽快重试，可以调小扫描周期，但代价是数据库压力变大。

REPEAT_字段用于重复定时器。比如你要让定时器事件每 5 分钟触发一次，总共触发 3 次，表达式可能是R3/PT5M。引擎处理起来并不是只存一条作业，而是每执行完一次就根据表达式计算出下一次的DUEDATE_，更新这条作业记录，或者根据需要生成新的作业。所以你在查询ACT_RU_JOB时，可能会看到一条REPEAT_不为空的作业反复出现，这不是故障，是正常的循环调度。

新版本里如果重试次数耗尽，作业可能被移动到专门的死信作业表，或者留在当前表但RETRIES_=0。死信的核心含义是“自动处理已经结束，需要人工决策”。此时你直接修改RETRIES_把作业拉回正常队列是可以的，但必须搞清楚为什么失败。如果业务代码有 bug，重置再多次也没用，反复失败还会给日志系统制造噪音。

4. 排障实战：定时器不触发、重试归零、孤儿作业和锁竞争

4.1 定时器到期不触发：先查这五步

如果你有一个定时边界事件，到期后流程没往下走，第一件事不是改业务代码，而是查作业表。打开数据库执行下面这条 SQL，看有没有对应的作业记录：

SELECT ID_, TYPE_, DUEDATE_, RETRIES_, LOCK_OWNER_, LOCK_EXP_TIME_, EXCEPTION_MSG_ FROM ACT_RU_JOB WHERE PROCESS_INSTANCE_ID_ = '你的流程实例ID';

如果查询结果是空，说明作业根本没生成，问题可能出在流程定义解析或者到达定时器节点前流程就异常了。如果有一条记录但DUEDATE_比当前时间晚，说明时间还没到，检查服务器时钟即可。如果DUEDATE_已经到了，但LOCK_OWNER_不为空且LOCK_EXP_TIME_也没过期，说明有另一个节点正在执行或者刚崩过，等锁超时再看。

如果作业上RETRIES_=0并且EXCEPTION_MSG_有内容，那才是业务执行失败导致的停摆。另外别忘了确认 Job Executor 确实启动了。Activiti 配置里通常有个开关叫asyncExecutorActivate，没打开的话整个调度线程都不跑，作业会全部停留在ACT_RU_JOB里，看起来就像定时器集体失灵。

这套连锁检查我写过很多次，每次都能快速定位 90% 的问题。核心原则就是：先看表里有没有作业，再看作业状态正不正常，最后才怀疑代码。

4.2 重试归零的作业如何安全重置

当一条作业已经RETRIES_=0时，你通常会看到类似“作业执行失败”的异常信息。要恢复它，理论上可以直接更新表：

UPDATE ACT_RU_JOB SET RETRIES_ = 3, EXCEPTION_MSG_ = NULL, EXCEPTION_STACK_ID_ = NULL, LOCK_OWNER_ = NULL, LOCK_EXP_TIME_ = NULL WHERE ID_ = '作业ID';

但我不建议你上来就执行这条 SQL。因为异常堆栈存在ACT_GE_BYTEARRAY里，如果只是把EXCEPTION_STACK_ID_置空，字节数组就成了孤儿数据。更重要的是，如果失败原因还没解决，重置后它就会再次失败，再次把堆栈写进去。比较安全的做法是用 Activiti 的管理 API，把作业移到死信表或者让作业重新尝试执行；如果只能手工操作，务必先摘掉锁、清零异常信息，并且在低峰期做。

还有一个很容易踩的坑：你手动重置了RETRIES_，但作业的LOCK_OWNER_还挂着某个已经宕机的节点名，LOCK_EXP_TIME_没超时。此时 Job Executor 不会碰这条作业，重置等于没重置。一定要把锁字段一起清掉。如果节点其实还在运行，只是数据库会话断了，清锁会导致两个节点重复执行同一个作业。所以生产环境重置前，先确认那个节点到底死没死。

4.3 孤儿作业的识别与清理

所谓孤儿作业，就是作业还留在ACT_RU_JOB里，但它关联的执行实例或者流程实例已经不存在了。常见原因是流程实例被手工从数据库删除，或者历史数据被清理任务删了但作业没有级联处理。排查方法很简单：

SELECT j.ID_, j.PROCESS_INSTANCE_ID_, j.EXECUTION_ID_ FROM ACT_RU_JOB j LEFT JOIN ACT_RU_EXECUTION e ON j.EXECUTION_ID_ = e.ID_ WHERE j.EXECUTION_ID_ IS NOT NULL AND e.ID_ IS NULL;

查出来的记录，基本可以判断为孤儿作业。处理时优先尝试用引擎的删除接口，让引擎自己清理相关数据。如果你只能直接 SQL 操作，删除前至少确认对应流程实例确实已删除，不要误删还在正常等待的作业。

还有一个相关场景：流程实例已经结束，但作业还在。正常情况下流程实例结束后作业会被清理，但如果你使用了内嵌子流程、边界事件跨作用域，偶尔会出现清理不干净的情况。这时候把关联的PROCESS_INSTANCE_ID_与ACT_HI_PROCINST对比，如果历史里流程实例已经完成，作业基本可以安全删除。

4.4 多节点集群下的锁竞争问题

多节点部署时，锁竞争是ACT_RU_JOB最典型的麻烦。之前我在一个模拟项目里见过两个节点同时消费一批作业，最初配置的锁超时时间是 5 秒，而作业处理器要等一个外部接口，平均耗时 8 秒。结果一个作业刚执行 5 秒，锁就过期了，另一个节点立刻抢走同一份作业，外部接口被调用了两次，下游出现重复数据。

这种问题的解法不是简单的把锁超时时间调大，而是要理解作业处理器的耗时分布。如果大部分作业都在几百毫秒内完成，只有少数慢作业，可以考虑给慢作业单独处理，或者调大整体锁超时时间。另一个办法是让外部接口实现幂等，这样即使重复执行也没有副作用。技术方案上，避免长时间占用作业锁永远是第一原则。

另外，多个节点要确保时钟一致。LOCK_EXP_TIME_和DUEDATE_都是基于时间的，如果一个节点时间快了三分钟，它可能在锁刚过期时立刻抢回来，但业务时间判断也会错乱。生产环境一定要配置统一的 NTP 时钟同步，这是最小成本、最大收益的优化。

4.5 作业表膨胀与参数调优

如果ACT_RU_JOB长期几万行、几十万行，要先看这些作业是哪种类型。定时器等待是正常的，比如大量流程都等 7 天，那表里必然有大量未到期作业。真正危险的是大量RETRIES_=0的失败作业，或者异步继续作业堆积。失败作业堆积意味着业务故障没有及时处理，异步继续作业堆积则通常是线程池不够或者数据库连接池被占满。

监控时可以分组统计：

SELECT TYPE_, COUNT(*), MAX(DUEDATE_), MIN(DUEDATE_) FROM ACT_RU_JOB GROUP BY TYPE_;

如果async-continuation数量持续很高，多半是 Job Executor 的线程池跑不过来。Activiti 的异步执行器有几个关键参数可以调，比如核心线程数、最大线程数、每次获取的作业数量、锁超时时间等。不同版本参数名可能不完全一样，但核心思路是：一次不要捞太多作业，线程池要扛得住突发的并发量，锁超时时间要大于绝大多数作业的执行耗时。

数据库层面，要给ACT_RU_JOB关心的高频查询建合适的索引。比如按DUEDATE_查询到期作业，按PROCESS_INSTANCE_ID_查某流程实例的作业。Activiti 的建表脚本里通常自带基础索引，但如果你有很多自定义查询，还是要自己确认执行计划。索引也不是越多越好，写频繁的表索引太多会影响插入性能。

5. 围绕 ACT_RU_JOB 的几个认知误区与日常维护清单

5.1 四个容易让人误判的认知误区

第一个误区是把它当成历史日志表。ACT_RU_JOB里存的是“还没有做完”或“还没到时间”的作业，不是流水账。作业一旦执行成功就会被删除，所以你看到这张表永远只能看到当前和未来，看不到过去。有人做数据归档时想把这张表当成历史表同步走，结果把等待执行的任务也搬走了，流程全部卡住。

第二个误区是手动清理表数据来解决积压。有人看到作业表太大，直接DELETE FROM ACT_RU_JOB，结果所有正在等待定时器的流程实例全部断掉，而且引擎内存里的实体对象还认为作业存在，后续提交直接抛乐观锁异常。想清理作业，一定要先搞清楚为什么要清理。失败作业要修异常，过期作业要核实流程状态，孤儿作业要确认关联的流程实例已经没了。

第三个误区是认为RETRIES_设置的越大越好。重试机制是用来兜底网络抖动和临时故障的，不是用来掩盖业务代码异常的。设置成 100 次，慢慢失败的作业会反复跑 100 个周期，占用线程和数据库资源。更合理的做法是保持默认的 3 次左右，配合死信表或告警通知，让运维人员及时介入。

第四个误区是只要有定时器，就必须依赖 Job Executor。如果项目里已经有成熟的任务调度平台，完全可以由外部系统在指定时间调用引擎 API 发起流程或触发事件，把ACT_RU_JOB的负担减到最低。Activiti 的作业表适合流程引擎内部的轻量定时语义，不适合替代专业调度系统来做海量定时任务。

5.2 日常监控和维护清单

日常维护不复杂，但要有固定的检查节奏。我习惯每天看两条 SQL：一是查失败作业数，也就是RETRIES_=0或者EXCEPTION_MSG_不为空的行数；二是查锁定过期数，也就是LOCK_OWNER_不为空且LOCK_EXP_TIME_小于当前时间的行数。失败作业数长期大于 0，说明有业务问题没解决；锁定过期数频繁出现，说明有节点崩溃或者有耗时过长的作业。

每次发版涉及定时器事件、异步任务或作业处理器改造时，我会提前在测试库跑一遍完整的作业生命周期：生成作业、等待到期、执行成功、确认删除；再模拟一次失败，确认重试次数递减和异常信息写入是否正确。这套流程虽然简单，但能规避大多数低级问题。

再分享最后一个排障技巧：很多异常的根因不在ACT_RU_JOB本身，而在它的关联数据里。我看到定时器不触发，除了查作业表，还会立刻查ACT_RU_EXECUTION和ACT_HI_ACTINST，确认流程实例是不是已经处于奇怪的状态。只有把执行实例、任务、作业三者结合起来看，才能快速还原出完整的现场。这也符合排查任何数据库表问题的通用逻辑：不要只看一张表，要看数据之间的关系。