做Java开发这些年最让我头疼的不是业务逻辑写不出来而是线上报了一堆异常却找不到根因。尤其是像NullPointerException这种日志里密密麻麻堆了几百行翻到最后发现是某个对象没判空。今天把这两年处理Java异常的经验整理一篇专门讲高频错误怎么排查、异常体系怎么设计、性能怎么优化。这篇文章适合刚入行的同学建立异常处理的整体认知也适合写了两三年业务代码但遇到异常还是靠猜的朋友。内容全部来自实际项目和踩坑记录不是教科书式的理论堆砌。先说一个总观点异常处理不是简单的try-catch它是一套从代码设计到线上排查的完整方法论。如果你只知道语法遇到线上问题依然会手足无措。接下来我按“设计逻辑 - 高频问题 - 优化重构 - 排查工具”这条线展开。1. 异常处理的设计与底层逻辑1.1 从JVM角度看异常机制不了解JVM怎么处理异常就很难理解为什么有些人说“不要滥用异常”。Java里所有异常和错误都继承自Throwable往下分为Error和ExceptionException又分为受检异常和非受检异常RuntimeException。这个体系本身是为了表达“程序运行时出了什么问题”但JVM真正执行异常抛出和捕获时付出的代价比大多数开发者想象的高。每次执行throw new XXXException()JVM都要做两件事创建异常对象并填充堆栈轨迹StackTraceElement数组。填充堆栈需要抓取当前线程的调用栈这个操作非常昂贵比普通new对象慢几十倍甚至上百倍。你写一个“用异常做判断条件”的代码等于在算法循环里不断生成完整堆栈性能自然就崩了。另一个容易被忽略的点是JVM在编译try-catch时会生成异常表ExceptionTable其中记录了try范围、catch类型和跳转地址。异常抛出时JVM会在这张表里线性查找合适的catch块找不到就继续向上层抛。整个过程虽然有优化但和普通的if判断相比逻辑复杂得多。所以我在代码评审时经常会问这段逻辑真的需要抛异常吗如果可以用if判断优先用if。异常只留给“不可预料的、无法通过普通条件判断避免的情况”。这不仅是性能问题也是代码可读性问题。1.2 受检异常和非受检异常怎么选Java设计受检异常Checked Exception的初衷是强制调用方处理“可恢复的、可预料的”错误比如IOException、SQLException。但实际项目里受检异常用多了会非常痛苦每个方法都throws调用方要么继续往上抛要么catch后包一层代码很快被异常声明淹没。反过来非受检异常RuntimeException不强制声明调用方可以忽略适合表达“编程错误”或“不可恢复状态”比如NullPointerException、IllegalArgumentException。现代Java生态Spring、MyBatis等也更倾向于非受检异常Spring把JDBC的SQLException包装成DataAccessException原因就是不想让业务代码被一层层throws绑架。我个人的选型建议是组件/框架底层对外提供的API如果遇到“外部IO、文件、网络”这类可恢复错误可以用受检异常但不要传播太远。业务层校验失败、状态非法、参数错误一律用非受检异常配合全局异常处理器返回友好的错误信息。永远不要为了“编译器强制我处理”而写空catch那比不处理更可怕。很多Java面试题也会问“受检异常和非受检异常的区别”但面试官真正想听的往往不是背诵定义而是你在真实项目中怎么权衡。你如果能讲清楚“受检异常把错误处理成本强加给调用方非受检异常把控制权交给调用方现代框架更喜欢后者”就能稳稳过关。1.3 最常见的三类异常反模式第一个反模式用异常控制业务流程。典型代码是这样的从列表中查找符合条件的对象找不到就catch一个NoSuchElementException然后走另一个分支。这会让代码执行路径藏在异常堆栈里排查问题时看到的堆栈也误导人。正确做法是先用if/contains判断或者用Optional.ofNullable加orElse。第二个反模式catch之后吞掉异常。我看到过很多catch块里只写一句log.debug或者干脆空着理由是“这个异常不影响主流程”。问题是等线上出现诡异现象时这个被吞掉的异常往往就是根因。如果真的认为某个异常不影响主流程至少要在日志里保留完整的异常堆栈后续排查时才有据可查。第三个反模式catch Exception后继续执行高危操作。比如事务里catch了数据库异常然后return success数据实际没写进去用户却看到成功。正确做法应该是区分可恢复异常和不可恢复异常对于无法恢复的直接抛出并回滚即使要兜底也要明确记录失败原因并通过告警通知而不是悄悄吞掉。2. 高频错误排查实录从日志到根因2.1 NullPointerException 排查套路NullPointerExceptionNPE是所有Java开发遇到最多的异常没有之一。我以前处理过一个问题线上某个接口突然大量报NPE堆栈指向service层的getOrderId()但代码里根本看不到明显的null来源。后来我做了三件事才定位第一把堆栈的行号对应到编译后的class文件第二在本地用同样参数复现第三在IDE里给异常处打断点调试时查看当前对象的所有字段。很多人可能不知道如果项目编译时保留了行号信息默认是有的堆栈里能直接看到“类名.java:行号”这非常关键。如果看不到行号多半是打包时开了混淆或者编译器参数设置问题需要去排查构建配置。排查NPE的实操心得先在异常堆栈里找到“哪个对象可能为null”通常是点号前面的那个字段。用IDE的“Evaluate Expression”在断点处执行表达式例如order.getUser().getName()看哪一步返回null。如果本地复现不了在代码里临时加Objects.requireNonNull(obj, obj is null)或防御性判断并通过日志输出关键字段。尽量让NPE信息更明确使用java.util.Objects.requireNonNull可以自定义错误信息比裸的NPE好排查一百倍。预防NPE方面我现在的习惯是外部传入的参数在方法入口统一校验从数据库或缓存取出的对象先用Optional包装链式调用超过两层就考虑是否拆开用局部变量。不是所有地方都要判空但在“数组、集合、外部接口返回值”这些重灾区宁多勿少。2.2 下标越界与格式转换异常IndexOutOfBoundsException也是一个高频异常最常见的场景是for循环里用i list.size()却硬取get(i)或者subList后没注意大小。有个经典误区for (int i 0; i list.size(); i)边界条件写成了最后一个元素访问不到越界异常倒是直接报出来。这类问题用增强for或Stream迭代基本就能避免但如果你需要下标可以用List.get(i)前先判断i size()。NumberFormatException常见于把字符串转数字Integer.parseInt(input)遇到非数字内容直接抛异常。我接手过一个报表系统每天凌晨跑批都会挂后来发现是上游系统偶尔返回“12a”这种脏数据。解决方案是在解析前先用正则做一次校验input.matches(-?\d)不合法的记录单独记日志并按默认值处理。这样既避免了大量异常实例开销也保证了批处理稳定性。还有一个相关异常是ClassCastException一般出现在强转类型时。比如从Map里取值拿到的是Integer你强转成String或者泛型擦除后从List里取元素强转。排查时看异常信息里的“java.lang.Integer cannot be cast to java.lang.String”直接定位两端的类型不匹配。最有效的预防是少用裸转型多用泛型必要的时候用instanceof做类型检查。这些转换类异常还有一个共同点报错信息往往带着具体的输入值比如“For input string: 12a”。看到这类日志第一反应不是盯代码而是找这个输入值是从哪个环节来的。很多时候是上游数据质量问题链路排查比改代码更重要。2.3 集合遍历与并发修改异常ConcurrentModificationException是遍历集合时修改集合导致的。最典型的是在foreach里直接list.remove(item)因为增强for底层的迭代器会在remove后检查modCount发现和预期不一致就抛异常。解决办法用Iterator的remove()或者用Collection.removeIf()或者收集要删除的对象后统一removeAll。实际生产环境里这类异常还会出现在多线程并发访问同一个ArrayList的场景。有个老掉牙但很经典的例子HashMap在JDK 7及以前并发put可能导致死循环和CPU 100%JDK 8改进了链表转红黑树的逻辑但依然不支持并发写。所以多线程环境下优先使用ConcurrentHashMap如果业务对数据一致性要求不高也可以用CopyOnWriteArrayList做读多写少的list。说到底集合选型本身就是一种异常预防策略。排查这类问题的思路是看异常堆栈里是哪个迭代器抛的然后分析操作是否跨线程。我遇到过某系统里一个单例对象持有ArrayList被多个线程边读边写调用方还觉得“加了synchronized就没事了”结果synchronized锁的是另一个对象。后来把共享集合换成线程安全实现问题才彻底消失。2.4 SQL与数据库连接相关异常数据库类异常中最高频的是唯一键冲突MySQL报“Duplicate entry xxx for key uk_code”Spring里对应的异常是DuplicateKeyException。遇到这种情况不要直接catch整个Exception而应该针对唯一键冲突单独处理。比如注册接口用户手机号已存在时先查一次再插入也不能完全避免并发正确姿势是捕获DuplicateKeyException并返回“手机号已注册”。连接池超时是另一个让人头疼的问题“HikariPool-1 - Connection is not available, request timed out after 30000ms”。很多人第一反应是“连接池不够用”于是盲目调大最大连接数结果数据库被拖垮。实际上80%的情况是连接泄漏某处获取了Connection但没关闭finally里也没释放。排查这个问题的技巧是开启连接池的泄漏检测例如HikariCP可以设置leakDetectionThreshold长时间未归还的连接会在日志里输出获取时的堆栈直接定位到泄漏代码。还有一类是锁等待超时update/insert操作报“Lock wait timeout exceeded”。这通常和大事务、批量操作没提交、或者死锁有关。排查手段包括查数据库的processlist看哪些事务持锁时间过长代码层面则需要控制事务粒度避免在事务里做远程调用、循环查库等耗时操作。记住数据库连接和事务是有限资源任何资源都需要有明确的获取和释放边界。2.5 内存溢出与栈溢出虽然OutOfMemoryError和StackOverflowError不是Exception但它们比任何异常都致命。OOM最常见的是Java heap space直观表现是应用变卡、频繁Full GC、接口大面积超时最后直接宕机。排查步骤我总结成先用jmap -heap看看堆内存使用情况再用jmap -dump:formatb,fileheap.bin导出堆快照然后用MAT或VisualVM分析哪些对象占了内存。重点看有没有大集合没清空、线程池队列积压、或者G1在Mixed GC时老年代碎片化。StackOverflowError的定位相对简单堆栈里全是同一行递归调用基本就是递归没有终止条件。比如对象A配置了JSON序列化循环引用A包含BB又包含AtoString时无限递归。解决办法是给字段加JsonIgnore或使用引用关系来中断链条。除递归外如果一个方法的局部变量特别多也会占用较大的栈帧但这种情况很少见。这里分享一个个人习惯遇到内存问题别急着改JVM参数先把堆dump拉下来看对象分布。我见过很多团队一上来就调大-Xmx结果只是把问题延缓了几周。真正定位到Root Cause才能根治。3. 异常处理的优化技巧与代码重构3.1 自定义异常体系设计很多项目喜欢直接throw new RuntimeException(xx失败)这样确实省事但问题也很明显调用方无法根据异常类型做精准处理只能靠异常信息里的字符串匹配非常脆弱。更好的做法是设计一套统一异常体系一个BaseException继承RuntimeException内部包含错误码、错误信息、附加上下文再派生出BizException、SystemException等。我在项目中习惯这样设计public class BizException extends RuntimeException { private final Integer code; private final MapString, Object context; public BizException(Integer code, String message) { super(message); this.code code; this.context new HashMap(); } public Integer getCode() { return code; } public void addContext(String key, Object value) { context.put(key, value); } }这样controller层的全局异常处理器就能根据code返回统一响应体。比如参数错误返回400库存不足返回409用户无权限返回403。同时context里可以塞入订单号、用户ID等排查信息让异常自带上下文而不是只有一句干巴巴的话。自定义异常还有一个细节在构造函数里把root cause传进去。如果你catch了底层异常再抛出自定义异常时一定要写成throw new BizException(code, msg, e)Java的异常链才能保留原始堆栈。很多人直接抛new BizException(msg)导致底层SQLState、受检异常全部丢失线上看到的是一个没有cause的孤儿异常排查成本直接翻倍。3.2 try-with-resources 与资源释放在Java 7之前关闭资源的经典代码是try-catch-finally习惯在finally里调用close()。但这里有个坑如果try块抛了异常Aclose()又抛了异常Bfinally里的B会覆盖A原始异常被吞掉日志里看到的只有B真实原因A就丢了。我踩过这个坑排查了很久才发现是资源关闭时的IOException覆盖了业务异常。Java 7引入的try-with-resources就是为了解决这个问题。它要求在try括号里声明的资源必须实现AutoCloseable然后不管正常结束还是异常抛出都会自动调用close()。如果try块和close()都抛异常try的异常会作为主异常抛出close的异常会被追加为suppressed异常这样原始异常不会丢失。它底层其实是编译期帮你生成了close逻辑并不是魔法。现在项目里我基本不用手写finally来关连接尤其是数据库连接、Redis连接、文件流、网络流这四大类资源。例如try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { // 业务处理 } catch (SQLException e) { throw new BizException(500, query failed, e); }注意顺序一定是从外层到内层声明右括号后的分号表示全部声明完毕。如果你在try块内手动创建流的场景也可以使用“局部变量自动关闭”的增强用法Java 9但建议还是遵守传统写法兼容性更好。3.3 日志规范与异常上下文异常堆栈本身是重要信息但光有堆栈往往不够。比如日志里只看到“NullPointerException at OrderServiceImpl.getOrderLine:120”没有订单号你怎么复现所以打日志时必须带上关键业务参数。我推荐这个格式log.error(getOrderLine error, orderId{}, userId{}, orderId, userId, e)其中最后一个e表示把异常堆栈完整地打到日志里。另一个实践是引入MDCMapped Diagnostic Context。在网关或过滤器中每次请求生成一个traceId放到MDC里这样日志框架会自动把它拼到日志行。之后无论日志走到哪个类靠traceId就能串起整个请求链路。排查高并发问题的时候这个字段就是救命的锚点。还有一些日志禁忌不要去记录密码、token、身份证号等敏感信息。即使是异常日志也要先过滤敏感字段。另外不要用e.printStackTrace()它会把堆栈打到标准输出在容器环境里很可能丢失或混杂统一使用日志框架的error方法才能通过日志级别的配置灵活控制输出。3.4 性能优化异常不是越少越好吗前面说了异常创建成本很高但不是说“不能用异常”而是不要用异常来处理正常流程。比如解析数字这种场景如果你明确知道用户可能输入非数字优先用正则或Character.isDigit校验而不是直接Integer.parseInt再catch。这属于“用可预期的判断替代异常分支”。另一个性能优化点是减少包装异常导致的多层堆栈。我见过一个函数调用链A抛异常 - B捕获后包装 - C捕获后包装 - D捕获后打印最终堆栈里有四段suppressed异常日志文件大得离谱。正常情况下在同一逻辑边界包装一次就够了不需要每层都重新包装。如果是为了给异常增加上下文可以用addSuppressed来记录低层异常而不是重抛新异常。还有一个偏门但有效的技巧如果某个异常确实极其频繁而且你不需要堆栈可以通过-XX:-StackTraceInThrowable参数关闭堆栈填充但这个参数是全局的且会严重影响可排查性除非非常确定线上异常已经稳定否则不要在生产用。我还是倾向于正常代码用判断避免异常真正的异常路径保留完整堆栈。4. 线上排查工具与高频问题速查表4.1 高频异常速查表我把这些年遇到过的高频异常整理成一张表方便遇到问题时快速对照。表格只是起点每一类问题背后都可能有多重原因需要结合实际场景深入分析。异常类型典型报错信息常见原因排查入口解决方向NullPointerExceptionCannot invoke xxx because yyy is null对象未初始化、外部返回null堆栈行号、IDE断点判空、初始化、OptionalClassCastExceptionclass Integer cannot be cast to class String类型强转错误、泛型擦除查看转换两端类型使用泛型、instanceof校验NumberFormatExceptionFor input string: 12a字符串非数字检查输入来源正则校验、默认值兜底IndexOutOfBoundsExceptionIndex 5 out of bounds for length 5循环边界、List越界检查下标计算增强for、边界判断ConcurrentModificationExceptionnull遍历时修改迭代中集合被改查看堆栈调用点Iterator.remove、removeIf、线程安全集合DuplicateKeyExceptionDuplicate entry xxx for key uk_code唯一索引冲突查看具体键值捕获后提示友好信息HikariPool timeoutConnection is not available, request timed out连接泄漏、配置过小开泄漏检测、查processlisttry-with-resources、调大连接池Lock wait timeoutLock wait timeout exceeded; try restarting transaction大事务、锁竞争数据库processlist缩小事务、控制并发OutOfMemoryErrorJava heap space堆内存对象过多jmap dump、MAT分析修复内存泄漏、调整堆参数StackOverflowErrorStackOverflowError递归无终止、JSON循环引用查看重复堆栈帧终止条件、忽略循环引用4.2 常用排查工具与命令JVM自带工具永远是第一选择。jstack用于导出线程dump可以看线程状态、锁等待、死锁jmap用于查看堆内存信息和导出dump注意导出操作会触发Full GC在高峰期要谨慎。Arthas是阿里开源的在线诊断工具它的watch、stack、trace命令能在不改代码的情况下查看方法调用参数、返回值和异常堆栈非常适合线上问题定位。这些工具都不是什么神秘技术熟练使用它们能大幅缩短排查时间。我自己用Arthas最多的场景是“线上方法突然抛异常但日志看不到参数”。直接用watch命令监控目标方法watch com.example.OrderService getOrderLine {params, throwExp} -x 3它会实时打印调用该方法的入参和异常对象不需要重启应用不需要加日志代码。还有stack命令可以查看当前线程的执行路径tt命令可以记录调用现场并回放。对于Java开发来说Arthas是居家旅行必备案头工具。日志分析也是排查的一环。如果你们接入了ELK或者类似日志平台搜索traceId就能把一次请求的完整链路拉出来。没有日志平台的话至少保证日志文件里每一行都有时间戳和线程号通过grep过滤线程号也能拼出一次调用的轨迹。4.3 我踩过的几个坑第一个坑全局异常处理器里只打了异常消息没打完整堆栈。结果线上报错后只能看到“订单状态不正确”这七个字完全不知道哪行代码触发。后来我强制要求所有异常日志必须打完整堆栈并且业务异常也要带上下文参数。第二个坑在finally里关闭资源时用了一个静态的logger打日志但关闭流本身抛了异常把主逻辑异常覆盖了。那一次问题定位花了两天最后在测试环境复现才看到suppressed异常。后来全面改成try-with-resources问题彻底消失。第三个坑自定义异常时只写了message忘了填cause。有一次调用远程接口底层抛的是SocketTimeoutException我这层包装成BizException后没传cause结果监控看到的是“调用外部系统失败”却没有具体是哪个系统、什么超时。后来代码规范里明确规定包装异常必须传入cause否则不允许抛出。第四个坑在lambda表达式里直接抛受检异常。Java的lambda函数式接口默认不允许抛受检异常很多人会写一个wrap成RuntimeException的工具方法。如果wrap时没把cause传进去这条链路会丢掉真实异常。后来我们统一用了一个CheckedFunction工具类内部包装时始终把原异常设为cause并且自定义UncheckedException类型保证异常链完整。5. 最后再分享几个小习惯如果让我给新人提几条异常处理的建议我会说第一写代码时先问自己“这个异常真的会发生吗”用if和校验把概率降到最低第二catch块里不要吝啬日志把入参、状态、堆栈全记录下来第三所有外部IO和资源操作一律使用try-with-resources第四自定义异常必须包含错误码和cause方便上层统一处理第五遇到不熟悉的异常不要急着改代码先复现、再定位、再修复。还有一个我个人的偏好每次代码评审时我都要看一眼新增的try-catch块有没有打日志、有没有把异常转换成有业务含义的错误信息。不夸张地说一个项目里异常处理的质量往往能体现这个团队的真实工程水平。很多面试题看起来是让背语法实际上考察的正是你在实际系统中对异常边界的把控力。把这篇文章里的思路吃透下次再面对堆满异常日志的线上环境你应该不会像以前那样慌了。最后如果你正在调试某个接口反复报错建议直接在IDE里设置“Break on uncaught exceptions”让程序在第一次抛出未捕获异常时自动停下然后用调试器看调用栈和变量。省下的时间够你泡好几杯咖啡了。