80后程序员的避坑指南：专属于80后的回忆源码解析

报错一堆看不懂 StackTrace？别慌，这不是你的错，是环境变了。

很多80后开发者转岗或接手老项目时，常遇到这种尴尬：代码看着没问题，一跑就崩，满屏红色报错，日志里全是 NullPointerException 或 ClassCastException。

这期【避坑指南】不聊虚的，直接扒开底层，用一段经典源码讲透异常处理机制，帮你从“看天书”变成“看门道”。

入口定位：异常是如何被捕获的

在 Java 世界中，每个方法调用都有成本，而异常处理是最昂贵的成本之一。很多老项目为了“稳”，到处包 try-catch，结果性能下降，代码难维护。

我们来看 JDK 源码中 Thread 类的 run 方法，这是所有线程执行的入口。这里有一个容易被忽略的细节：当线程执行过程中抛出未捕获异常时，JVM 并不会直接杀死进程，而是调用 UncaughtExceptionHandler。

这段逻辑在 JDK 1.8 及以后版本中非常关键，尤其对于长期运行的服务来说，理解它意味着你能控制“线程死亡”后的行为。

// 源码位置: java.lang.Thread
public void run() {if (initLocals) {// 初始化线程本地变量initLocals = false;Thread.initLocals();}// 核心逻辑：执行任务if (target != null) {try {target.run();} catch (RuntimeException | Error err) {// 这里捕获的是运行时异常和错误// 注意：这里没有捕获 Checked Exception// 因为 target.run() 本身不抛出受检异常uncaughtException(this, err);}}
}

逐行解析：

1. if (initLocals)：每个线程首次执行 run 时，需要初始化线程本地变量（TLS）。这是为了防止多线程共享内存导致的脏读。
2. target.run()：target 就是你传入的 Runnable 实例。真正业务逻辑在这里执行。
3. catch (RuntimeException | Error err)：这里只捕获非受检异常。这是设计者的意图——Runnable.run() 签名中没有 throws 子句，所以编译器强制你只能处理非受检异常。
4. uncaughtException(this, err)：当异常逃逸出 try 块时，JVM 会调用这个静态方法。默认行为是打印堆栈信息到 System.err，并终止线程。

关键洞察：

很多80后开发者习惯在业务代码里写 catch (Exception e)，然后 e.printStackTrace()。这在单元测试里没问题，但在生产环境是灾难。因为 printStackTrace 会阻塞 I/O，且日志格式不可控。

正确的做法是：在顶层入口（如 main 方法或线程池的 RejectionHandler）统一捕获，使用 SLF4J 或 Log4j2 记录结构化日志。

核心片段：异常堆栈的生成机制

为什么 StackTrace 看起来那么长？因为每次异常抛出，JVM 都要遍历调用栈，收集每个方法的类名、方法名、行号。这个过程非常耗时。

我们看 Throwable 类的 fillInStackTrace 方法，这是生成堆栈信息的源头。

// 源码位置: java.lang.Throwable
private native Throwable fillInStackTrace();

虽然这里是 native 方法，无法直接看到 Java 代码，但我们可以看 Exception 的子类 RuntimeException 的构造过程。在 HotSpot 虚拟机中，fillInStackTrace 会调用 java.lang.StackTraceElement 数组来存储信息。

为了更直观，我们看一个简化的模拟实现，展示堆栈是如何被构建的：

public class StackTraceSimulator {private final List<String> stackTrace = new ArrayList<>();// 模拟方法调用public void methodA() {stackTrace.add("methodA");methodB();}public void methodB() {stackTrace.add("methodB");methodC();}public void methodC() {stackTrace.add("methodC");throw new RuntimeException("模拟异常");}public void simulate() {try {methodA();} catch (RuntimeException e) {// 模拟 JVM 的行为：打印堆栈System.out.println("Exception: " + e.getMessage());for (String frame : stackTrace) {System.out.println("    at " + frame + "()");}}}public static void main(String[] args) {new StackTraceSimulator().simulate();}
}

逐行解析：

1. stackTrace.add("methodA")：每进入一个方法，我们将方法名压入栈。这模拟了 JVM 调用栈的行为。
2. throw new RuntimeException("模拟异常")：异常抛出时，当前栈帧是 methodC。
3. catch 块中：我们遍历 stackTrace 列表，打印每个方法。注意，实际 JVM 中堆栈是从上到下（最新调用在最上），这里为了简化，我们按顺序打印。

性能陷阱：

在高频调用路径上，频繁创建异常对象（new Exception()）会导致大量 GC 压力。因为每个异常对象都会触发 fillInStackTrace，这是一个 O(n) 操作，n 是调用栈深度。

避坑技巧：

• 不要使用异常控制流程。例如，不要用 try-catch 来判断文件是否存在，应该使用 Files.exists()。
• 如果必须捕获异常，尽量在顶层捕获，避免多层嵌套。
• 对于高频路径，考虑使用 ThreadLocal 缓存异常对象，或者使用“快速失败”策略。

设计思想：为什么异常机制是这样设计的

Java 的异常设计遵循两个核心原则：最小化异常处理范围 和 区分可恢复与不可恢复错误。

1. 受检异常（Checked Exception）：编译器强制你处理。例如 IOException、SQLException。这些异常通常是可恢复的，比如文件读取失败，你可以重试或提示用户。
2. 非受检异常（Unchecked Exception）：包括 RuntimeException 和 Error。编译器不强制处理。这些异常通常是程序 bug，比如 NullPointerException、ArrayIndexOutOfBoundsException，或者系统级错误，比如 OutOfMemoryError。

设计者的意图：

• 受检异常用于“业务逻辑错误”，提醒开发者注意边界条件。
• 非受检异常用于“程序缺陷”，应该被修复，而不是被捕获。

80后开发者的常见误区：

很多老代码中，看到 catch (Exception e) 就懵了，不知道里面到底捕获了什么。其实，Exception 是所有受检异常和非受检异常的父类，但 Error 除外。

正确的做法是：

• 在业务层，只捕获具体的受检异常，如 catch (IOException e)。
• 在顶层入口，捕获 Throwable 或 Exception，记录日志并返回友好错误页面。
• 永远不要捕获 Throwable 后吞掉异常，这会导致问题被掩盖，难以排查。

权威参考：

根据 Oracle 官方 Java 教程（Java SE 17 Documentation），异常处理的最佳实践是：“Catch only those exceptions that you can handle.”（只捕获你能处理的异常）。这句话看似简单，但90% 的开发者都没做到。

手写简化版：实现一个轻量级异常处理器

为了深入理解，我们手写一个简化的异常处理器，模拟 JVM 的行为。这个例子虽然简单，但能帮你理解“异常如何被传播”和“如何被捕获”。

public class SimpleExceptionHandler {// 模拟调用栈private static final ThreadLocal<List<String>> STACK = ThreadLocal.withInitial(ArrayList::new);public static void push(String methodName) {STACK.get().add(methodName);}public static void pop() {List<String> stack = STACK.get();if (!stack.isEmpty()) {stack.remove(stack.size() - 1);}}public static void handleException(Exception e) {System.out.println("Caught: " + e.getMessage());List<String> stack = STACK.get();for (int i = stack.size() - 1; i >= 0; i--) {System.out.println("    at " + stack.get(i) + "()");}STACK.remove(); // 清理 ThreadLocal，防止内存泄漏}// 模拟业务方法public static void businessMethodA() {push("businessMethodA");try {businessMethodB();} catch (Exception e) {// 在 A 层捕获，但这里我们选择重新抛出，模拟向上传播throw new RuntimeException("A failed", e);} finally {pop();}}public static void businessMethodB() {push("businessMethodB");try {// 模拟异常throw new Exception("B failed");} finally {pop();}}public static void main(String[] args) {try {businessMethodA();} catch (Exception e) {// 顶层捕获handleException(e);}}
}

逐行解析：

1. ThreadLocal<List<String>> STACK：使用 ThreadLocal 模拟每个线程独立的调用栈。这是多线程环境下保证线程安全的关键。
2. push 和 pop：模拟方法调用时的栈帧入栈和出栈。finally 块确保即使发生异常，栈也会被正确清理。
3. handleException：遍历栈，从最新调用开始打印。注意，这里我们从后往前遍历，模拟堆栈的 LIFO 特性。
4. businessMethodA 中的 catch：我们捕获异常后，包装成 RuntimeException 重新抛出。这模拟了“异常向上传播”的过程。
5. main 方法：顶层捕获异常，调用 handleException 打印堆栈。

关键设计点：

• finally 块：无论是否发生异常，finally 块都会执行。这是清理资源（如关闭文件、释放锁）的最佳位置。
• 异常包装：在传播过程中，将低层异常包装成高层异常，可以保留上下文信息，同时隐藏底层实现细节。
• ThreadLocal 清理：在 handleException 最后调用 STACK.remove()，防止内存泄漏。这是使用 ThreadLocal 时的常见坑。

应用场景：从老项目迁移到新框架

80后开发者在转岗或接手新项目时，常遇到老项目与新框架的兼容性问题。例如，从 Spring MVC 3 迁移到 Spring Boot 3，异常处理机制发生了变化。

场景1：Spring MVC 3 的 @ExceptionHandler

在 Spring MVC 3 中，@ExceptionHandler 只能捕获当前控制器方法抛出的异常，无法捕获过滤器（Filter）或拦截器（Interceptor）中的异常。

场景2：Spring Boot 3 的 ErrorController

Spring Boot 3 引入了 ErrorController，可以统一处理所有未捕获异常。默认情况下，它会返回一个标准的错误页面（如 /error）。

迁移避坑指南：

1. 检查异常传播路径：确保异常从 Controller 层能传播到 ErrorController。如果中间有 try-catch 吞掉了异常，ErrorController 就收不到。
2. 自定义错误响应：在 ErrorController 中，根据异常类型返回不同的 JSON 响应。例如，404 返回“资源不存在”，500 返回“系统内部错误”。
3. 日志记录：在 ErrorController 中记录完整堆栈信息，便于后续排查。注意，不要在生产环境返回详细堆栈给用户，避免信息泄露。

代码示例：

@RestController
public class GlobalExceptionHandler implements ErrorController {@Override@RequestMapping("/error")public ResponseEntity<Map<String, Object>> handleError(HttpServletRequest request) {Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);String message = (String) request.getAttribute(RequestDispatcher.ERROR_MESSAGE);Map<String, Object> body = new HashMap<>();body.put("status", statusCode);body.put("message", message);// 记录日志System.err.println("Error occurred: " + message);return new ResponseEntity<>(body, HttpStatus.valueOf(statusCode));}
}

逐行解析：

1. @RequestMapping("/error")：Spring Boot 默认将错误请求转发到 /error 路径。
2. request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE)：获取 HTTP 状态码。
3. request.getAttribute(RequestDispatcher.ERROR_MESSAGE)：获取错误消息。
4. System.err.println：记录日志。在生产环境，应使用 SLF4J。
5. new ResponseEntity<>(body, HttpStatus.valueOf(statusCode))：返回 JSON 响应，并设置正确的 HTTP 状态码。

最后提醒：

在处理异常时，永远不要忽略异常。即使你无法处理，也要记录日志并重新抛出。忽略异常是导致系统崩溃的最常见原因。

你更常用哪种写法？评论区交流