在移除代码中的 @Schedule 或 @Timeout 定时器后，JBoss 仍会在 jboss_ejb_timer 表中保留对应记录；虽不再触发，但若定时器到期，系统会因找不到目标 Bean 而抛出异常，因此需手动清理 PostgreSQL 中的过期定时器条目。
在移除代码中的 `@schedule` 或 `@timeout` 定时器后，jboss 仍会在 `jboss_ejb_timer` 表中保留对应记录；虽不再触发，但若定时器到期，系统会因找不到目标 bean 而抛出异常，因此需手动清理 postgresql 中的过期定时器条目。
JBoss AS / WildFly 的 EJB 定时器机制将定时任务元数据持久化至数据库（如 PostgreSQL 中的 jboss_ejb_timer 表），以保障集群环境下的高可用与故障恢复能力。该表不会自动清理已从代码中删除的定时器——即使应用重启、Bean 类被移除或方法签名变更，原有定时器记录仍滞留于数据库中。
当这些“僵尸定时器”到达预定触发时间时，容器尝试反序列化并调用已不存在的 Bean 或方法，最终抛出类似以下异常：
java.lang.IllegalArgumentException: No EJB found for timer ... Caused by: java.lang.ClassNotFoundException: com.example.OldTimerBean
✅ 正确做法：在部署新版本前，主动清理数据库中失效的定时器记录。
以 PostgreSQL 为例，可通过以下 SQL 安全删除无对应类/方法的定时器：
-- 1. 查看待清理的定时器（建议先执行此查询确认） SELECT id, timer_state, bean_class_name, timed_object_id FROM jboss_ejb_timer WHERE bean_class_name NOT IN ( SELECT DISTINCT class_name FROM your_app_deployed_classes -- 需根据实际部署信息补充校验逻辑 ); -- 2. 删除所有属于已下线 Bean 的定时器（推荐按 bean_class_name 精确匹配） DELETE FROM jboss_ejb_timer WHERE bean_class_name = 'com.example.OldTimerBean'; -- 3. 或更通用方式：删除所有非当前活跃应用相关的定时器（配合 app_name 字段，若使用） DELETE FROM jboss_ejb_timer WHERE app_name = 'old-app-name' AND timer_state = 'ACTIVE';
⚠️ 注意事项：
- 执行前务必对 jboss_ejb_timer 表进行备份（如 pg_dump -t jboss_ejb_timer mydb > timer_backup.sql）；
- 生产环境建议在维护窗口期操作，并确保应用已完全停止或处于只读状态；
- 若使用 WildFly 26+，可结合 CLI 命令 timer remove --timer-id=xxx 管理单个定时器，但批量清理仍依赖 SQL；
- 长期建议在 CI/CD 流程中加入“定时器一致性检查”步骤，例如通过脚本比对源码注解与数据库记录。
总之，jboss_ejb_timer 是有状态的持久化存储，而非临时缓存——“删代码 ≠ 删定时器”。主动治理残留数据，是保障 EJB 定时任务系统稳定、避免隐蔽异常的关键运维实践。
