写Java也写了十个年头了异常处理这个话题每年都会翻出来聊但每次看新人的代码还是会头皮发麻。有的把异常当摆设catch完打一行日志就当无事发生有的把异常当万能药任何业务分支都用抛异常解决。异常处理不是Java语法里最难的那一坨但绝对是最能看出一个程序员功底的地方也是面试必问、上线必踩的环节。这篇内容我打算系统地把Java异常处理从头到尾捋一遍从异常体系本身到底层机制从实战策略到性能考量再到高频问题的排查思路。无论你是刚学Java准备面试的在校生还是工作中时不时被线上异常困扰的初级开发甚至是想帮团队定一套异常规范的组长这篇都能给你一些可以直接用的东西。1. 异常体系全景先搞清楚Java到底把“错误”分成了几类很多初学者看了不少异常处理的代码但问起Throwable和Exception、Error之间的关系还是说不明白。这个搞不清楚后面设计异常和处理策略都会跑偏。1.1 Throwable家族不要把Error当Exception来处理先看最顶层的Throwable这是Java里所有“可以被抛出”的对象的共同父类下面分了两大派系Error和Exception。Error表示的是JVM层面的严重问题比如OutOfMemoryError、StackOverflowError、NoClassDefFoundError。这类问题基本不是你的代码能“捕获后恢复”的捕获了也没用因为程序此时大概率已经处于半瘫痪状态。所以常规处理原则就一句话不要在代码里捕获Error也不要去处理它让它直接冒泡让JVM和应用进程一起完蛋然后靠监控报警去拉起来。我还有一点要特别提醒catch (Throwable t)这种写法在大项目里几乎等于定时炸弹。Throwable是连Error一起捕获的有些监控框架会用它来做兜底记录但如果你在业务代码里写这种捕获就等于把OOM也一并吞了后面出现诡异的内存问题排查起来非常痛苦。Exception是程序运行中可恢复、可处理的问题比如文件找不到、网络超时、参数不合法。这才是我们日常要重点关注的。1.2 受检异常与非受检异常语法规定背后的历史包袱Exception又进一步分成两类受检异常Checked Exception和非受检异常Unchecked Exception。受检异常是编译器强制要求你处理的典型就是IOException、SQLException。如果你调用了一个会抛受检异常的方法你就必须“声明throws”或者“try-catch”否则代码编译不过去。这个设计是Java早期的理念认为程序应当对可预见的错误显式处理。但后来的实践表明这个设计过度理想化了——很多时候你根本没法在当前位置处理这个异常却还是被逼着写了一堆try-catch最后只是把异常包一层又抛出去纯属增加噪音。非受检异常就是RuntimeException的子类以及Error。这类异常编译器不管你可以选择不捕获。NullPointerException、IllegalArgumentException、ClassCastException、IndexOutOfBoundsException都属于这一类。它们代表的通常是编程逻辑错误或前置条件未满足本来就该在代码层面提前规避而不是依赖运行时的异常处理机制。有个非常关键的区别需要理解Spring事务默认只在RuntimeException非受检时回滚受检异常默认不回滚。这个特性让后来绝大多数Java框架更倾向于使用RuntimeException。所以现在写Java新代码里基本不推荐自定义受检异常除非你明确知道调用方必须处理。1.3 自定义异常应该怎么选父类自定义异常是项目中不可避免的。你总会需要一个BizException或者BusinessException来表示业务规则被违反。我的建议是业务异常统一继承RuntimeException。理由主要有三个。第一因为Spring事务默认回滚不会出现事务提交了一半结果的情况。第二不用在每个业务方法上逼着调用方声明throws代码更干净。第三可以通过异常类型做统一拦截比如在ControllerAdvice里统一处理成错误码返回给前端。继承层次不要太深统一一个顶层业务异常类就够了。如果确实需要细分可以考虑用异常内部的错误码枚举来区分而不是搞出一堆异常子类。我见过有些项目里业务异常子类几十个维护起来非常麻烦新增一个错误场景就要新建一个类。2. 核心机制解析try、catch、finally和try-with-resources的深层逻辑异常处理语法本身不复杂但真正用好的不多。这一章我重点拆解几个容易出问题的机制细节。2.1 try-catch-finally执行顺序与finally陷阱正常场景下try块里代码顺序执行一旦抛出异常直接跳到对应的catch块无论是否发生异常finally块都会执行。这个大家都懂但下面几个边界场景很容易踩坑。第一个陷阱是finally里的return。如果try或catch里有return语句而finally里也有return那么finally里的return会覆盖前面的返回值。更离谱的是如果finally里抛出了异常try和catch里原本的异常会被完全掩盖。这类代码在code review时一定要直接打回finally块里只做清理资源这类工作不要return、不要throw。第二个陷阱是System.exit()。如果在try块里调用了System.exit()JVM进程直接终止finally块不会执行。有些同学面试会被问“finally一定执行吗”标准答案就是要排除JVM退出和线程中断这类场景。第三个陷阱是catch的顺序。多个catch块时子类异常必须放在父类异常前面否则编译器直接报错。比如catch (IOException e)必须在catch (Exception e)前面。道理其实很简单异常匹配是自上而下找第一个能匹配的catch块如果先写了父类子类异常就被父类“截胡”了。try { // 业务代码... } catch (FileNotFoundException e) { // 更具体的处理逻辑 } catch (IOException e) { // 更通用的IO处理逻辑 }2.2 try-with-resources资源关闭的标准答案如果你还在用finally去关闭流或数据库连接我建议把这段看完。Java 7引入的try-with-resources才是资源关闭的标准姿势它要求资源类实现AutoCloseable接口InputStream、OutputStream、Connection这些都实现了。让我用一个非常实际的多资源场景来演示。以前要正确关闭两个流必须写嵌套的try-finally还得处理各自的异常代码又长又容易出错// 推荐写法try-with-resources多个资源用分号分隔 try (InputStream input new FileInputStream(input.txt); OutputStream output new FileOutputStream(output.txt)) { byte[] buffer new byte[1024]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } }你不需要手动close编译器会自动生成关闭逻辑而且关闭顺序是逆序的后声明先关闭对应先开output再关output再关input。还有一点做得非常讲究如果try块和close方法都抛出了异常Java会优先保留try块里的原始异常同时把close阶段抛出的异常作为“被抑制异常”挂到原始异常上。你可以用getSuppressed()方法拿到它们。这样排查问题时不会被莫名其妙的关闭异常干扰主方向这个设计值得手动点赞。2.3 throw与throws异常是怎么传播上来的throws是方法声明的一部分表示“我这个方法可能抛出这个异常调用方自己要心里有数”。throw则是主动抛出一个异常实例。两者动作不同但经常在一段代码里配合出现。传播规则是这样的异常从最先发生的地方逐层往外抛如果每一层都不捕获最终会到达线程的顶层处理器。对于主线程异常会直接导致程序退出并打印堆栈。对于线程池里的线程情况要复杂一些这个后面会单独说。有个最佳实践要强调在做异常转换和包装的时候一定要保留原始堆栈。比如你写throw new BizException(库存不足, e);这个构造方式会把e作为cause传进去。而你写成“手动拼接消息”的话throw new BizException(库存不足: e.getMessage());就丢失了原始异常的完整堆栈排查问题时几乎等于废掉了一条重要线索。所以永远记住cause参数必须传这是异常处理最基本的职业素养。3. 实战中的异常处理策略什么时候捕获、什么时候抛出、什么时候自定义机制明白了真正难的是策略。异常处理本质上是“在哪里处理最合适”的问题处理早了破坏封装处理晚了又容易堆满日志。3.1 捕获粒度别在底层捕获你处理不了的异常新手最常见的错误是在方法内部把异常catch掉再打一行日志然后继续往下走。这种“假装处理”的代码是最毒的因为程序返回值或后续逻辑很可能已经处在一个错误状态但表面上一片安静等到数据错乱了才显示出问题。核心原则是在当前这个层级能做出有效应对才捕获如果不能就往上抛。什么叫有效应对比如你写的是接口的入口层那你可以捕获业务异常并转换为约定的错误码返回给前端比如你写的是定时任务批处理那你可以捕获单条数据的异常并标注这批次里哪些数据失败继续处理后面的数据。这些都是有效应对。如果只是中间层做数据组装、调用外部服务、读文件你没有能力决定“失败后对用户说什么”那就别捕获让异常继续往上走由统一出口处理。3.2 自定义业务异常与错误码别一股脑抛Exception自定义业务异常的核心价值是让错误信息结构化。一个合格的自定义异常要能表达三层信息发生了什么、影响谁、具体是哪个上下文。我常用的做法是定义一个带错误码枚举的BizException再加一个字段用来携带上下文数据。比如一个导入订单的功能抛出异常时除了错误码还可以把失败的那一行数据一起带上。这样统一处理时能直接把“第xx行数据不合法”这样的提示返回给前端。public class BizException extends RuntimeException { private final ErrorCode errorCode; private final String context; public BizException(ErrorCode errorCode, String context) { super(String.format(%s: %s, errorCode.getMessage(), context)); this.errorCode errorCode; this.context context; } // getter省略... }这里有一个细节异常message要包含足够的参数方便日志排查。我经常看到有人抛出异常时只写“参数错误”日志里根本不知道是哪个参数错了、值是多少。能把参数值拼进异常消息就能省掉很多日后的“考古工作”。3.3 异常日志规范同样一段代码日志价值天差地别异常处理和日志是伴生关系处理得再好日志打不好线上问题一样抓瞎。先说不好的写法。第一种是 catch 后只打一行e.getMessage()然后当作没事。第二种是log.error(error)不带任何异常对象。第三种是printStackTrace()把堆栈打到标准输出一旦线上系统把stdout重定向到别的文件你根本不知道日志去哪了而且这种写法在分布式系统里完全无法和请求链路关联。推荐的做法是用日志框架的占位符并且在最后一个参数传入异常对象这样框架会自动打完整堆栈try { orderService.createOrder(orderDTO); } catch (BizException e) { log.error(创建订单失败, userId{}, orderNo{}, userId, orderNo, e); throw e; }这段日志的价值在于不但知道“创建订单失败”这个事实还有userId、orderNo这种排查问题的锚点最后还有完整异常堆栈。如果业务里还接入了traceId那就更完美了一个链路上下游的异常都能串起来。4. 性能与并发场景异常处理不能拖垮系统“性能”这个词大部分人是不会第一时间和异常处理联系在一起的但等你的系统上了量级异常的性能开销就会变得非常明显。4.1 为什么异常创建比普通对象创建贵异常的昂贵之处不在try-catch本身而在throw new的那一刻。JVM在创建异常对象时要填充线程当前调用栈也就是抓取栈帧快照这个操作比普通new一个Object高出两三个数量级。更致命的是如果你在循环里频繁抛出异常这个开销会被放大几十倍。所以实战里有一条铁律不要用异常做控制流。我见过有人用NumberFormatException来判断字符串是不是数字用ArrayIndexOutOfBoundsException来检测数组结束这些都属于典型的错误示范。正确做法是直接用正则、Character.isDigit()或显式判断。// 反例异常控制流 try { int val Integer.parseInt(str); } catch (NumberFormatException e) { // 认为不是数字 }如果你确实要对所有字符串做转换并容忍非法值可以在高频路径上用“前置校验parse”组合或者干脆在外面catch但内部已经限定了这个方法的调用频率。总之异常是给“不该发生但发生了”的情况准备的不是给“预期会发生”的事情准备的分支逻辑。4.2 批量处理中的异常隔离一条坏数据不应该带崩整批批处理是异常设计最容易失衡的场景。一条脏数据抛个异常如果没处理好整批任务戛然而止之前处理完的几千条全部白做。但如果每条都捕获、打印堆栈那日志量和CPU开销又不划算。正确设计思路是把单条捕获和失败收集结合起来循环内逐条捕获收集错误到List不中断批量循环外根据错误数量决定是继续还是告警。同时日志层面要做降噪相同错误码只记录一次完整堆栈后续只计数。ListString failMessages new ArrayList(); for (OrderDTO dto : batchList) { try { processOne(dto); } catch (BizException e) { failMessages.add(订单 dto.getOrderNo() 失败: e.getMessage()); } } if (!failMessages.isEmpty()) { alarmService.sendBatchWarn(batchId, failMessages.size(), failMessages.stream().limit(20).collect(Collectors.toList())); }还有个经验批处理里最怕的是“无差别异常捕获”把程序Bug也当作业务失败一样吞掉。我的建议是只catch预期的BizException和明显的可恢复异常对于RuntimeException跑出来的程序缺陷应该让它中断一次打出一个完整堆栈然后修复代码而不是伪装成一条失败记录继续跑。4.3 线程池和异步任务中的异常处理异常不会自动消失只会自动被吃掉用线程池的时候有个普遍误区以为任务里的异常会自动像主线程那样打印出来。其实Exception在execute()方式提交的任务里会被线程池的run()方法捕获然后静默丢弃。也就是说你在业务代码里没捕获的异常线上日志里什么都看不到任务看起来是“没报错”地消失了。这非常危险。如果你用ExecutorService的execute(Runnable)提交任务一定记得给线程池设置一个UncaughtExceptionHandler作为全局兜底日志。如果你用的是submit(Callable)任务里的异常会被存储在Future内部必须调用future.get()才会被重新抛出。所以submit之后最好结合Future的get结果统一处理别调了submit就彻底不管了。ThreadPoolExecutorExecutor pool new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new NamedThreadFactory(order-async), new ThreadPoolExecutor.AbortPolicy() ); pool.setUncaughtExceptionHandler((t, e) - log.error(线程池任务异常, thread{}, t.getName(), e));5. 常见问题速查与排查技巧实录与其把每个异常类都背一遍不如掌握一套排查思路。我在这一章里把高频异常整理成一份速查表再结合真实案例讲讲排查链路。5.1 高频异常案例NPE、ClassCastException、IndexOutOfBoundsNullPointerException在所有线上异常里排第一。排查NPE的核心是读堆栈Java高版本会精确提示“Cannot invoke xxx because the return value of xxx is null”直接定位是哪个调用null了。如果堆栈信息里看不出来最快的办法是在IDE里设置 “NPE breakpoint”开启断点条件后异常抛出的那一瞬间就能看到当前作用域里每个变量的值。它最让人头疼的是各种“伪装NPE”比如Stream里map中调用方法返回null后续reduce直接炸。规避思路无非两个要么源头杜绝用Optional Objects.requireNonNull尽早暴露要么在边界防御对关键接收对象做isNull判断。ClassCastException通常不是“强转错类型”而是类加载器问题或泛型擦除带来的假象。我遇到过的情况包括不同jar包带了同一个类的不同版本代码里强转成另一个ClassLoader加载的版本直接ClassCastException。排查时除了看堆栈还要看是哪个ClassLoader加载的这两个类。至于IndexOutOfBoundsException常见于遍历时删元素、计算数组索引越界处理原则是“用迭代器删除、无把握就用for倒序或stream filter”。速查表整理如下异常类型常见诱因排查重点NullPointerException调用链中某个中间值为null高版本直接看堆栈提示是哪个方法调用导致ClassCastException强转类型不匹配、类加载器不一致加JVM参数打印类加载器确认jar版本IndexOutOfBoundsException集合动态修改、索引计算错误检查循环下标、删除操作方式IllegalArgumentException参数校验失败但被忽略看是否进入异常控制流的错误场景OutOfMemoryError堆内存泄漏或堆参数过小dump堆再分析大对象、GC Roots引用链5.2 用堆栈信息定位问题的“Caused by”才是关键排查异常的第一个动作不是看第一行而是看完整的堆栈链特别是Caused by后面的部分。尤其在异常被层层包装后只有追到根因才能真正解决问题。我举个例子一个调用第三方接口的服务一直报BizException面上消息是“调用超时”。表面看是接口问题但继续往下翻Caused by是SocketTimeoutException再往下还有一层Caused by是DNS解析超时。真正要处理的是DNS服务器速度而不是给接口超时加长。如果只看第一层这个问题永远解决不了。所以我在团队里反复强调“看堆栈只看到Error Line就开始回复这是最不专业的排查方式。” 至少要看完整堆栈的caused by链。5.3 线上异常排查的完整链路traceId 日志级别 分组告警线上问题比本地复现难得多核心武器是链路追踪和日志。一个请求从网关进入后都会由框架生成traceId并塞进MDC。这样一条请求在多个服务间的所有日志都带着同一个traceId用grep一拉就能还原整条链路。异常排查最基础的操作就是报错发生时先用异常信息里的关键字搜traceId再把这条traceId的所有日志按时间顺序捋一遍。日志级别这里也要有讲究。不要把业务异常的ERROR级别当洪水猛兽在批量任务中一条数据失败是正常情况级别应该用WARN只有整批失败、服务不可用、内存异常才应该用ERROR。不然日志系统里全是ERROR真正严重的问题反而不容易区分。告警这块我建议按异常类型分组而不是按服务维度无脑触发。BizException可以单独设置低频告警NPE和类转换异常这类程序Bug可以整页邮件告警Infrastructure异常网络超时、数据库连接池打满要走独立的高优告警通道。6. 团队规范与异常处理的长期修养很多人以为异常处理是“语法技巧”但一个项目里异常处理好不好更多取决于团队有没有形成一致的规范。有些原则是靠日积月累沉淀出来的。6.1 异常处理相关的团队规约宁可少吞不可多写我参与过的几个项目都定了一些异常相关的规约核心大致是禁止捕获异常后不处理、不输出、不重新抛出。实现了“处理”就一定要有动作。禁止捕获Exception后只打e.getMessage()不打堆栈。禁止用异常控制业务流程比如用parse异常当校验分支。禁止在循环中创建、抛出、捕获异常来做分支判断。业务异常必须使用统一异常类和统一错误码禁止直接抛new RuntimeException(中文提示)。禁止在finally里return或throw这是代码review必挂项。这些规约不是教条每条背后都有一次深刻的线上事故或者繁琐排查的教训换来的。6.2 从“会用异常”到“设计异常”像设计API一样设计你的异常更高一层的异常处理能力是把异常当作API的一部分来设计。这就意味着异常类型名要说明问题本质比如OrderExpiredException而不是BizException 105异常message要有可操作性异常里要能带上下文参数调用方要能从异常中知道下一步该怎么处理。比如一个支付回调接口抛出的异常类型如果叫PaymentStatusMismatchException里面有orderId、currentStatus、expectedStatus调用方一看就知道是状态流转不对而不是一头雾水地再去查数据库。好的异常设计能显著减少跨部门扯皮尤其在对接第三方系统时异常信息越明确联调效率就越高。6.3 最后再分享一个真正值钱的经验从我个人经验来说排查异常时最容易犯的错误是过度依赖异常本身而忽略了正常路径下的上下文现场。异常只是“结果先生留下的通知”真正的问题往往发生在抛异常之前的几步。比如数组越界越界只是结果循环边界算错了才是根因校验失败只是结果数据是怎么被污染的才是根因。所以我现在排查异常时会养成一个习惯不仅看异常堆栈还要顺着日志往前翻30秒看看异常发生前这个请求都经历了什么。绝大多数诡异问题的答案其实都在那段“看似正常”的日志里。这也是我把异常处理定义为“长期修养”的原因——它不是几个语法点而是一整套排查问题、设计代码的思维方式。
