crontab中java命令找不到，因默认环境极简、不加载profile，JAVA_HOME和PATH为空；应先用env和which验证，再改用绝对路径调用java。
crontab里java命令找不到，进程秒退
定时任务根本没跑起来，日志为空或只有java: command not found，这是最常见也最容易误判的情况。crontab默认环境极简，JAVA_HOME和PATH几乎为空，它不会自动加载~/.bashrc或/etc/profile。
- 先验证：在 crontab 里加一行
* * * * * /usr/bin/env > /tmp/cron_env.txt 2>&1，等一分钟看输出里有没有JAVA_HOME和含java的PATH - 再确认：
* * * * * which java >> /tmp/java_path.log 2>&1，如果日志为空，说明 shell 根本不认识java - 别绕弯子：直接用绝对路径调用，比如
/usr/lib/jvm/java-21-openjdk-amd64/bin/java -jar /opt/app.jar，这是最稳的解法
任务“卡住”但没报错，其实是被OOM Killer干掉了
现象是日志突然中断、进程消失、无OutOfMemoryError，连hs_err_pid*.log都不生成——这不是JVM抛异常挂的，是Linux内核直接KILL的。尤其在定时任务里反复拼大字符串（比如StringBuilder在循环中不断append），每小时吃一点内存，堆设得再大也扛不住长期累积。
- 查系统日志：
dmesg -T | grep -i "killed process"，看到类似Out of memory: Kill process 12345 (java) score 897就坐实了 - 别只盯
-Xmx：检查整个宿主机内存压力，free -h和cat /proc/meminfo | grep -i "oom\|commit" - 临时规避：给JVM加
-XX:+UseCGroupMemoryLimitForHeap（Docker/K8s场景下更关键）
Docker容器里时区不对，Cron时间全乱套
OpenJDK本身不依赖系统时区做调度，但@Scheduled或外部crontab解析Cron表达式时会用到系统时钟。Docker默认用UTC，如果你的Cron写的是0 0 * * *（每天0点），实际执行时间就是UTC 0点，相当于北京时间早上8点——你以为没跑，其实它早八百年就跑过了。
- 启动容器时加参数：
-e TZ=Asia/Shanghai，并挂载/etc/localtime:/etc/localtime:ro - Java应用内补一手：
-Duser.timezone=GMT+08，确保SimpleDateFormat、Calendar等行为一致 - 验证方式：进容器执行
date，输出必须是东八区时间；再跑个java -Duser.timezone=GMT+08 -c "System.out.println(new Date())"比对
Spring Boot @Scheduled在K8s里“间歇性失联”
Pod滚动更新后，旧Pod还没完全退出，新Pod已经拉起，但@Scheduled没做分布式锁，两个实例同时执行同一任务——不是“不执行”，而是你只看到其中一份日志，另一份可能写进了被删掉的Pod日志里，或者压根没打出来。
- 别信
spring.task.scheduling.pool.size能解决并发：这只是线程池大小，不是去重开关 - 真要单点执行，要么上
xxl-job这类中心化调度器，要么自己加DB或Redis分布式锁（注意锁续期和失效边界） - 最轻量方案：用K8s的
Job替代@Scheduled，每次触发都起一个独立Job Pod，天然隔离
真正卡住排查的难点，往往不在Java代码里，而在shell环境、系统资源、容器配置这三层交界处。一个which java返回空，比一百行StackOverflowError更值得优先盯死。
