Java进程“静默退出”本质是System.exit()调用或未捕获Throwable（含Error）导致JVM直接终止，不执行清理；排查应优先查退出码、strace捕获exit系统调用、jstack快照及JVM参数如-XX:+HeapDumpOnOutOfMemoryError。
Java进程突然消失，连日志都没打完？先查System.exit()和未捕获异常
Java里没有“静默退出”这个标准术语，但开发者常用来描述一种现象：程序没报错、没打印异常栈、进程却直接终止了。根本原因就两类：System.exit()被调用，或线程中抛出未捕获的Throwable（尤其是Error子类）。JVM遇到这两种情况会直接终止，不走正常清理流程，所以看起来“静默”。
排查时别急着翻业务日志——先看JVM退出码和系统级痕迹：
-
System.exit(n)会返回退出码n给操作系统，Linux下用$?立刻能查到； - 检查
nohup.out或启动脚本重定向的日志末尾，有没有Process finished with exit code字样； - 用
jstack -l <pid></pid>在进程刚挂时抓快照，如果失败，说明进程已彻底退出，不是卡死。
为什么UncaughtExceptionHandler没生效？线程模型和JVM生命周期是关键
你可能已经给线程设置了Thread.setDefaultUncaughtExceptionHandler()，但依然看不到异常堆栈。这不是配置失效，而是触发时机问题：
- 主线程（main thread）抛出未捕获异常时，
UncaughtExceptionHandler会被调用，但**调用完JVM仍会退出**——它只是给你一个“临终打印”的机会，不是阻止退出； - 守护线程（daemon thread）崩溃不会阻止JVM退出，哪怕它有异常处理器；
-
OutOfMemoryError等严重Error可能绕过部分异常处理机制，尤其在GC线程或JIT编译线程中发生时； - 如果异常发生在
Runtime.addShutdownHook()里，也不会触发默认处理器，且可能导致JVM强制杀掉。
示例：下面这段代码看似加了兜底，实际仍会静默退出
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
System.err.println("Caught: " + e);
e.printStackTrace(); // 这行会执行，但JVM随后仍退出
});
throw new RuntimeException("boom"); // 主线程抛出
-XX:+PrintExitOnExit和-XX:+PrintGCDetails这类JVM参数真能帮上忙吗？
不能直接定位静默退出，但能暴露背后线索。JVM本身不提供“记录每次exit来源”的开关，但这些参数可帮你排除干扰、确认行为：
-
-XX:+PrintExitOnExit并不存在——这是常见误解，JVM没有这个参数，别白费时间配； -
-XX:+PrintGCDetails和-Xlog:gc*（JDK 10+）能帮你判断是否因GC失败导致OutOfMemoryError后退出，注意看日志末尾是否有java.lang.OutOfMemoryError: Java heap space； -
-XX:+ShowMessageBoxOnError在Windows上触发错误时弹窗，适合本地调试，但生产环境慎用； - 真正有用的其实是
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，配合jhat或VisualVM分析内存泄漏源头。
线上环境怎么快速定位谁调了System.exit()？别只盯源码
源码搜System.exit(往往漏掉反射调用、字节码增强（如某些AOP框架）、或第三方库内部逻辑。更可靠的方法是运行时拦截：
- 用
-javaagent加载自定义Agent，在System.exit()方法入口插桩，打印调用栈——例如用Byte Buddy写一个简单Agent； - JDK自带
jcmd <pid> VM.native_memory summary</pid>看不出exit，但jcmd <pid> VM.info</pid>能看到JVM启动参数和当前状态，确认是否被外部信号（如kill -9）干掉； - Linux下用
strace -e trace=exit_group,exit -p <pid></pid>可捕获进程级退出系统调用，明确是JVM主动退出还是被杀； - 如果用Spring Boot，检查是否启用了
spring.main.register-shutdown-hook=false，这会让应用上下文关闭时不注册钩子，但不影响System.exit()本身。
静默退出最麻烦的点在于：它不留下明显痕迹，而开发者习惯性先查日志、再查代码，却忽略了JVM退出那一刻的系统态和调用栈快照。越早用strace或Agent卡住出口，越不容易被表象带偏。
