死循环可通过运行时状态观测定位：先用top和top -H找高CPU进程及线程，再用jstack/gstack/pidstat抓取调用栈确认卡点，结合vmstat、/proc/PID/stack等排除干扰，最后通过超时控制、JVM参数和systemd监控实现防护与追溯。
直接看进程行为和线程栈，死循环不会主动写日志，但会留下可观测痕迹。关键不是翻系统日志（如 /var/log/messages），而是抓运行时状态。
定位高 CPU 进程与线程
先确认是不是真有死循环在跑：
- 执行 top，按 P 排序，找 %CPU 持续 >90% 的进程；
- 记下 PID，再运行 top -H -p PID，观察哪些线程（TID）长期占满单个核；
- 若某线程 CPU 占用稳定在 99–100%，且长时间不降，高度疑似死循环。
抓取线程级调用栈（核心步骤）
死循环代码会卡在某个函数或指令位置，需通过栈快照定位：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 对 Java 进程：用 jstack PID > stack.log，再把高耗线程 TID 转十六进制（printf "%x\n" TID），在日志中搜索该值，看是否卡在 RUNNABLE 状态的 for/while 循环、空 while(true)、无退出条件递归等；
- 对 C/C++/Go 等原生进程：用 gstack PID 或 perf record -p PID -g sleep 5 && perf report，查看热点函数是否集中在某段逻辑内反复执行；
- 通用方式：用 pidstat -t 1 5 查看线程级 CPU 变化趋势，确认是否持续尖峰。
辅助验证：排除其他干扰因素
避免误判为死循环，要同步检查几个关键指标：
- 运行 top 头部看 %Cpu(s) 行：us 高 + id 接近 0 是典型特征；若 sy 或 wa 也高，大概率不是用户态死循环；
- 用 vmstat 1 观察 r（运行队列）是否持续 ≥ CPU 核数，说明任务在排队，符合死循环抢占 CPU 的表现；
- 检查 /proc/PID/stack（需 root）：可直接看到内核态调用链，若用户态函数反复出现在栈顶，也是强线索。
事后补救与日志建议
死循环本身不打日志，但可以主动加防护：
- 在应用中加入超时控制、计数断点、健康检查接口，让循环具备可中断性；
- 上线前启用 JVM 的 -XX:+PrintGCDetails 和 -XX:+PrintCompilation，异常编译或 GC 飙升有时是死循环副作用；
- 部署后开启 systemd 的 CPUAccounting=true，并用 systemctl show -p CPUUsageNS 追溯服务级资源突增时间点，关联业务日志排查。
