# 巡检计划的「7 天变 14 天」之谜：一个被初始化分支悄悄跳过的校验

>一条甲方反馈，追出了一个潜伏在 java.util.Timer 定时任务里的经典坑：新记录首次初始化走了和滚动计算完全不同的代码路径，校验被静默跳过，周期直接翻倍。全程排查思路 + 修复方案 + 可复用提示词，写给所有维护老系统的朋友。

## 一、痛点场景

我维护一套跑了多年的巡检系统（Tomcat Servlet 架构，前端 Web + PDA 两端）。核心调度逻辑很"复古"：`auto_run.jsp` 挂在 java.util.Timer 上，每 57 秒扫一遍 `T_INSPECTION_PLAN` 表，把到达 `ALERT_NEXT_TIME` 的计划触发报警，再把下次报警时间往后推一个周期。
甲方反馈：**常白班（RUN_TYPE2=5）的巡检计划，配的是 1 周周期，但提醒却隔了 14 天才来。**
这种 bug 最恶心的一点：它不报错、不抛异常，日志里一切正常，只是时间"悄悄"多了一周。而且周期类 bug 验证成本极高——改完代码，你至少要等一个完整周期才能确认效果。
## 二、排查过程

**第一步：对齐"预期"和"实际"。** 从 `T_INSPECTION_LOG` 里捞出该计划近几次触发时间，确认间隔确实是 14 天而非 7 天，排除甲方配置错误（比如误配了双周）。
**第二步：定位写入路径。** 顺着 `ALERT_NEXT_TIME` 的写入点逐行追踪，发现写入其实发生在两个场景：

| | | |
|:-:|:-:|:-:|
|场景|代码路径|是否走 `dayInspecTimesOK` 校验|
|新建计划，首次写入下次报警时间|初始化分支|❌ 不走|
|既有计划触发后滚动计算|主循环，`date + 7day`|✅ 走|
**第三步：复现根因。** 问题出在初始化分支：当用户配置的 `START_TIME` 不在 9:00-17:00 工作时段（比如早上 7 点保存的计划），首次写入 `ALERT_NEXT_TIME` 时**绕过了** `dayInspecTimesOK` 这个"时间必须在有效巡检时段内"的校验，直接写入了原始值。到第二次主循环触发时，代码再做 `date + 7day`——但基准已经是"错位的时间"，顺延后落点又不符合工作时段规则，于是又叠加了一次调整，最终整体跳到了两周后。
一句话总结：**初始化和滚动更新是两套路径，校验只挂在其中一套上。** 这类"新数据首次落库"分支恰恰是最容易被测试遗漏的地方——测试造数时谁会特意选一个 7 点钟的 START_TIME 呢？
## 三、修复方案

在 `auto_run.jsp` 约第 535-546 行（初始化分支写入 `ALERT_NEXT_TIME` 之前）加了约 10 行校验，核心思路：
```

```关键设计原则有两条：
1. **不改动主循环逻辑**。只把初始化入口的输入"洗"成合法值，让它天然通过后续校验——最小 diff，对跑了三年的老系统来说，改动面越小越安全。

1. **试运行验证**。这类周期 bug 修完后不能直接全面部署，我选择先让该计划在真实环境跑一个完整周期，确认 `ALERT_NEXT_TIME` 精确落在 7 天后的工作时段，再推广。

## 四、效果对比


| | | |
|:-:|:-:|:-:|
|指标|修复前|修复后|
|1 周周期实际触发间隔|14 天|7 天（工作时段内）|
|START_TIME 在非工作时段的计划|首次时间错位，逐次放大|自动对齐到 09:00|
|跨周末/节假日计划|可能落入非工作日|顺延至下一工作日|
|部署风险|—|10 行局部改动 + 一个周期试运行|
## 五、经验总结

1. **凡是"时间滚动计算"的定时任务，初始化分支和滚动分支必须复用同一套校验函数**。两套路径哪怕只差一个 if，就会在某个边界输入下分叉。

1. **排查周期类 bug，先从数据表里还原历史触发序列**，用实际间隔反推是"单次错位"还是"持续放大"，能少走很多弯路。

1. **老系统修复，最小 diff + 单周期试运行**是性价比最高的安全策略。

1. 这个 bug 也很适合交给 AI 排查。可直接复用这段提示词：

>我有一个基于 java.util.Timer 的定时任务，字段 ALERT_NEXT_TIME 的实际触发间隔是配置周期的 2 倍，且仅当 START_TIME 不在工作时段（9:00-17:00）时出现。请帮我：① 找出 ALERT_NEXT_TIME 的所有写入点；② 对比各写入路径是否走了同一套时间合法性校验；③ 给出不改主循环逻辑的最小修复方案。

排查过程中我把「列出所有写入点 → 对比校验路径 → 给最小修复」这个三步框架丢给 AI，它几秒钟就指出了初始化分支缺校验的问题——人工逐行追这类老 JSP 代码，至少要半天。工具迭代了，但「怀疑一切绕过校验的旁路」这个直觉，永远是排查的第一反应。

一条甲方反馈，追出了一个潜伏在 java.util.Timer 定时任务里的经典坑：新记录首次初始化走了和滚动计算完全不同的代码路径，校验被静默跳过，周期直接翻倍。全程排查思路 + 修复方案 + 可复用提示词，写给所有维护老系统的朋友。

【征文】《巡检计划的「7 天变 14 天」之谜：一个被初始化分支悄悄跳过的校验》

数据库

巡检计划周期从7天变为14天的根因，在于初始化分支与滚动更新分支走了不同代码路径，校验被静默跳过。修复采用最小改动原则，在初始化入口补充校验，经过一个完整周期验证后，计划精准回归7天工作时段。这套排查框架与修复思路，适用于所有老系统定时任务的时间计算维护。

Java

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【征文】《巡检计划的「7 天变 14 天」之谜：一个被初始化分支悄悄跳过的校验》-腾讯云开发者社区-腾讯云

【征文】《巡检计划的「7 天变 14 天」之谜：一个被初始化分支悄悄跳过的校验》

【征文】《巡检计划的「7 天变 14 天」之谜：一个被初始化分支悄悄跳过的校验》

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐