Java异常丢失问题核心是日志断层与异常被静默吞掉，排查需分层验证：先确认是否丢失、再定位丢弃位置、最后堵住源头；重点查日志缺失、加全局未捕获钩子、扫空catch模式，并注意JVM栈剪枝优化影响。
Java异常丢失问题，核心是“该出现的日志没出现、该抛出的异常被静默吞掉”，导致故障难以复现、定位困难。排查不靠猜，而要分层验证：先确认异常是否真的丢了，再锁定丢在哪一层，最后堵住源头。
看日志有没有“断层”
空catch最典型的外在表现是日志缺失——不是报错少，而是关键步骤的日志整段消失。
- 搜索业务主干流程中的标志性日志，比如“开始处理订单”“调用支付接口成功”“写入数据库完成”，确认它们是否成对出现
- 对比正常时段与异常时段同一类请求的日志行数，若某次请求日志突然少了10行以上，大概率中间有异常被吃掉
- 特别关注异步线程（如 pool-1-thread-3）或协程ID的日志流，一旦该线程日志戛然而止，没有失败提示也没有后续动作，就是高危信号
加未捕获异常钩子兜底
在应用启动时注册全局处理器，把所有逃逸出来的异常单独记录：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> log.error("【未捕获】线程{}异常", t.getName(), e));
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 如果问题期间这个日志文件完全空白，说明异常没逃逸，而是被某个 try-catch 主动吞了
- 如果大量堆栈涌进来，重点查 @Async 方法、CompletableFuture 回调、线程池 submit/execute 提交的任务——这些地方容易漏掉异常捕获范围
- 注意 Spring 事务方法里 catch 了异常却不抛出，会导致事务不回滚，此时可比对数据库写入时间戳和日志时间是否错位来反推
扫代码里的“无效捕获”模式
以下 catch 块基本等于主动埋雷，必须清理：
- catch (Exception e) { } 或 catch (Throwable t) { } —— 没日志、没重抛、没兜底
- try-with-resources 里空 catch：try (FileInputStream fis = new FileInputStream("x")) { } catch (IOException e) { } —— 连资源关闭失败都吞掉
- @Transactional 方法内只 log.info("xxx") 却不带异常对象参数，等于把事务失效的关键线索抹掉
IDE 通常会标红并提示 “Swallowed exception”，别点 ignore；更可靠的是进 CI 加静态检查，比如 SonarQube 启用 IllegalCatchCheck 规则，从源头卡死。
留意 JVM 对高频异常的优化行为
不是所有“没堆栈”都是代码写的锅。JVM 在异常频繁抛出（比如上万次）后，可能触发栈轨迹剪枝优化，导致 printStackTrace() 输出只有 java.lang.NullPointerException 一行。
- 复现时可加 JVM 参数 -XX:-OmitStackTraceInFastThrow 关闭该优化，确保每次都有完整堆栈
- 生产环境慎用，仅用于诊断；长期方案是修复空指针根源，而非依赖参数兜底
- 这类问题多见于循环中反复调用含 NPE 风险的方法，建议用 Objects.requireNonNull 或 Optional 做前置校验
