企业官网建设流程全解析

Java 异常堆栈怎么读：三步挖到根因

报错一来，满屏 at com.xxx 向下滚。很多人的第一反应是复制第一行去搜索，搜到的帖子驴唇不对马嘴，改半天没用。问题出在读的位置。一个 Java 异常堆栈里，第一行往往只是包装，真答案住在最底下那个 Caused by 里。读堆栈是门三分钟能学会的手艺，学会了排查时间直接砍半。下面这张图先给你一个整体印象，后面逐块拆开讲。

一个堆栈的解剖

堆栈分三块，从上到下是异常头、调用帧、原因链。下面这张图把三块和它们的关系画出来，先看结构再读细节。
异常头是第一行，异常类型加 message。它只告诉你「出事了」，包装得多的话连「出了什么事」都看不准。

调用帧是接下来的每一行 at。一帧等于一次方法调用，格式是at 包名.类名.方法名(文件名:行号)。顺序从最内层出错的方法开始，一层层往外走，到线程启动为止。帧里还会出现一行... 3 more，意思是「和上面某段共同的帧省略了」，数字是省掉的帧数，看到它别找茬，这是 JVM 在省纸。

原因链是 Caused by 开头的段落。有人把异常抓到之后包一层再抛，或者框架帮你包了，就形成一条链。链的最后一环，最底下那个 Caused by，才是最初闯祸的异常。

三步读法

第一步，直接拉到底。看最底下 Caused by 的类型和 message，这是最初的真实错误。NullPointerException 说明有对象是空，SQLException 说明 SQL 出了事，ClassNotFoundException 说明运行时少了个类。搜索也搜这一行，不要搜最顶上的包装。注意：如果堆栈里只有一个异常、没有 Caused by，那第一行就是根因，直接看它即可。
第二步，在根因的帧里找你自己写的代码。根因帧往往一开头就是第三方库或者框架的类，往下翻，翻到包名是你公司域名的那一行，那一行就是你代码里出事的位置。框架的帧是路过的看客，你的那帧才是现场。

第三步，回到最外层，看包装链。每一层 Caused by 之间的「包了什么」回答的是另一个问题，谁在什么语境下把错误递了上来。IllegalStateException: 加载用户资料失败包着 NPE，语境就是「加载资料时炸了」，这个信息对定位有用，但它不是病因。

几个高频对照

JDK 14 之后的友好 NPE 值得单独认识。message 不再只有NullPointerException，而是Cannot invoke "String.trim()" because "name" is null，谁为空、调用什么失败了都写明。看到这种报文，第一步都可以跳过，病因已经写在脸上。

ClassNotFoundException 和 NoClassDefFoundError 长得像，语义完全不同。前者是运行时去找类没找到，多半是依赖缺失或者类名写错。后者是类在，加载或初始化它的时候炸了，多半是静态初始化块抛了异常或者依赖版本冲突。堆栈里认准这两个名字，排查方向一个向依赖走，一个向初始化代码走。

异步线程会吞栈。任务丢进线程池或者 CompletableFuture，堆栈断在CompletableFuture.supplyAsync这类帧上，看不到业务调用链。遇到断栈别顺着 at 找，去查任务提交的位置和异步边界。

亲手走一遍

下面用一段 Java 造一条被包装的异常链，直接运行java StackWalk.java（JDK 11+，JDK 17+ 能看到友好 NPE），对照三步读法读它打出来的堆栈。

// 直接运行：java StackWalk.java// 造一条被层层包装的异常，对照三步读法读它。publicclassStackWalk{staticStringqueryUserName(LonguserId){Stringname=null;returnname.trim();// 这里抛 NPE，第一处「自己写的代码」}staticvoidloadProfile(LonguserId){try{queryUserName(userId);}catch(NullPointerExceptione){// 包一层再抛，模拟业务层或框架的常见做法thrownewIllegalStateException("加载用户资料失败",e);}}publicstaticvoidmain(String[]args){try{loadProfile(42L);}catch(Exceptione){e.printStackTrace();// 按三步读法：// 第一步，最底的 Caused by 是 NullPointerException；// 第二步，根因帧里自己写的那行在 queryUserName；// 第三步，外层 IllegalStateException 只是包装，语境是「加载资料」。}}}

跑完对着输出走一遍三步，再回头看自己的报错，就是同一套动作。记住一句话：真答案住在最后一个 Caused by 里。如果一次没读顺，把堆栈贴到编辑器里，按「异常头 / 调用帧 / 原因链」三块用空行隔开，结构一眼就清楚了。

三个常见误区

拿最顶上的包装异常去搜索。搜到的是「怎么处理这个包装」，不是病因。

把框架的帧当问题点。at 里出现一大片 spring 或 mybatis 的类名，那是调用经过的路，不是出事的店。

忽略... N more去数帧。那是省略标记，不是丢失的线索。

适用边界

这一篇管堆栈怎么读。代码混淆过的堆栈要配合 mapping 文件还原，开了-XX:-OmitStackTraceInFastThrow才能拿到被 JIT 省略的堆栈，这类 JVM 开关和 APM 工具链不在范围内。Unknown Source 的帧说明编译时没带行号信息，定位粒度会粗一档。原则就一条：先找自己写的那一行，再看框架。想进阶的话，下一篇可以聊怎么用-XX:-OmitStackTraceInFastThrow和 APM 把被吞的栈捞回来。