Java定时任务需用唯一traceId关联日志、try-catch-finally统一记录状态、StopWatch自动统计耗时，并规避AOP失效、MDC未传递等陷阱。
在 Java 定时任务中记录开始和结束标记，核心是确保日志能清晰标识任务生命周期，便于排查执行时间、异常中断或重复触发等问题。关键不是“加两行 log”，而是让标记有上下文、可追溯、不被干扰。
用唯一 ID 关联开始和结束日志
避免只写“任务开始”“任务结束”，这样多任务并发时无法区分。推荐在每次执行时生成一个轻量级 ID（如 UUID 短码或时间戳+线程名）：
- 在任务方法入口处生成 ID，存入局部变量或 MDC（Mapped Diagnostic Context）中
- 所有该次执行的日志都带上这个 ID，包括异常堆栈
- 示例（使用 SLF4J + Logback）：
String traceId = UUID.randomUUID().toString().substring(0, 8);
MDC.put("traceId", traceId);
try {
logger.info("定时任务【userSyncJob】开始执行");
// ... 实际业务逻辑
logger.info("定时任务【userSyncJob】执行完成");
} finally {
MDC.clear(); // 必须清理，避免污染后续日志
}
捕获异常并统一记录结束状态
结束标记不能只靠正常流程到达，必须覆盖异常路径。否则任务崩溃后看不到“结束”，会误判为卡死：
- 用 try-catch 包裹全部逻辑，在 catch 中记录失败，在 finally 中记录“已退出”（但不重复记“完成”）
- 更推荐：定义一个执行结果枚举（SUCCESS / FAILED / INTERRUPTED），在 finally 中根据状态输出带语义的结束日志
- 示例：
String status = "SUCCESS";
try {
logger.info("【orderCleanupJob】启动（traceId={}）", traceId);
doCleanup();
} catch (Exception e) {
status = "FAILED";
logger.error("【orderCleanupJob】执行失败（traceId={}）", traceId, e);
} finally {
logger.info("【orderCleanupJob】已退出，状态={}（traceId={}）", status, traceId);
}
补充执行耗时，无需手动计算
光有开始/结束不够，耗时才是性能分析的关键。别用 System.currentTimeMillis() 手动减——容易出错且侵入业务：
立即学习“Java免费学习笔记（深入）”；
- 用 StopWatch（Spring 提供）自动计时，简洁可靠
- 把耗时作为结构化字段（如 JSON 日志中的 durationMs）或直接写进 message
- 示例：
StopWatch stopWatch = new StopWatch();
stopWatch.start();
try {
logger.info("【reportGenJob】开始（traceId={}）", traceId);
generateReport();
} finally {
stopWatch.stop();
logger.info("【reportGenJob】完成，耗时={}ms（traceId={}）",
stopWatch.getTotalTimeMillis(), traceId);
}
避免常见陷阱
这些细节看似小，却常导致日志失效或误导：
- 不要在 @Scheduled 方法外层加 AOP 日志：Spring 的定时代理可能绕过 AOP，导致日志缺失
- 异步任务要显式传递 MDC：若任务内启新线程（如 CompletableFuture），MDC 不会自动继承，需手动 copy
- 日志级别合理：开始/结束用 INFO；耗时超阈值（如 >5s）可 WARN；失败必须 ERROR
- 避免日志淹没：高频任务（如每秒执行）慎用 INFO 级开始/结束，可降为 DEBUG 或按条件采样
