`try-finally` 里的 `return`：为什么 `finally` 会悄悄改掉返回值、吞掉异常-尧图网络科技

前言

try-finally大家天天写，但下面这段代码的返回值，能一眼答对的人不多：

publicintgetValue(){intx=1;try{returnx;// 这里 return 的是 1？}finally{x=2;// finally 又把 x 改成了 2}}

返回1还是2？

更刁钻的是，如果finally里也写了return，或者finally里抛了异常，会发生什么？这些不是脑筋急转弯，而是真实项目里踩过的坑——尤其"finally吞掉异常"，能让一个本该炸出来的错误悄无声息地消失，排查起来能让人怀疑人生。

这篇文章讲清楚finally和return、异常之间那些容易被忽略的执行细节。

环境说明：本文基于 JDK 8。

一、先复现

复现 1：`finally`改了变量，返回值却没变

先揭晓开头那题的答案：

publicstaticintgetValue(){intx=1;try{returnx;}finally{x=2;}}// 调用：System.out.println(getValue());

返回的是1，不是2。finally里明明把x改成了2，返回值却还是1。很反直觉。

复现 2：`finally`里加个`return`，结果就变了

只把finally里的赋值换成return：

publicstaticintgetValue2(){intx=1;try{returnx;// 想返回 1}finally{return2;// finally 里也 return}}

这次返回的是2。try里的return x好像被finally的return覆盖了。

复现 3：`finally`里的`return`把异常吞了

最危险的一个：

publicstaticintgetValue3(){try{thrownewRuntimeException("出错了！");// 抛异常}finally{return-1;// finally 里 return}}

-1

注意：程序正常返回了-1，那个RuntimeException凭空消失了！调用方完全不知道里面出过错。这就是臭名昭著的"finally吞异常"。

三个现象，指向同一组问题：finally到底在什么时候、以什么顺序执行？它为什么能改返回值、吞异常？

二、根因

一句话总纲：try里的return并不是"立刻返回"，它会先把返回值"暂存"起来，然后一定要等finally执行完，才真正返回。finally就是在这个"暂存之后、真正返回之前"的空档里插了一脚。

2.1 复现 1：返回值在`return`那一刻就被"定格"了

return x的执行分两步：

计算并暂存返回值：把x当前的值（1）复制到一个临时位置（可以理解为"返回值寄存器"），这个值此刻就定格了；
执行finally；
真正返回那个暂存的值。

关键在于：finally里的x = 2改的是局部变量x，而返回值早在第 1 步就已经被复制走、和x脱钩了。所以改x影响不到已经暂存的返回值1。

小坑提醒：如果返回的是对象引用，情况有点不同。暂存的是"引用（地址）“，finally里若通过这个引用去修改对象内部的属性，改动是生效的（因为对象是同一个）；但若在finally里让变量指向一个新对象，则不影响已暂存的旧引用。记住：暂存的是"那一刻的值/引用”。

2.2 复现 2 和 3：`finally`里的`return`会"抢占"返回

如果finally里自己也有return，就完全是另一回事了：finally的return会直接终止方法，用它自己的返回值覆盖掉try里暂存的那个，并且丢弃try中待处理的return或异常。

复现 2：try暂存了返回值1，但finally执行到return 2时，直接带着2结束方法——暂存的1被丢弃。
复现 3：try里抛出的异常本应向上传播，但finally执行到return -1，方法直接正常返回-1——那个正在传播的异常被丢弃了，调用方永远收不到。

道理是一致的：finally里的return（或throw）会"截胡"，让try里原本要返回的值、要抛的异常统统作废。异常被吞，就是这么发生的。

三、正解：`finally`只做清理，别在里面`return`、别在里面抛异常

这些坑的根源，都是在finally里做了"改返回值/中断控制流"的事。规避原则很简单：

finally块只用来做资源清理（关流、解锁、还连接），绝不放return、throw，也不去修改要返回的变量。

// 反例：finally 里 return，吞掉异常publicintbad(){try{returnriskyCall();}finally{return-1;// ✗ 吞掉 riskyCall 的返回值和异常}}// 正解：finally 只清理，让返回值和异常正常传播publicintgood()throwsException{Resourcer=open();try{returnr.process();// 返回值/异常都能正常出去}finally{r.close();// ✓ 只做清理}}

更进一步，如果只是为了关资源，优先用try-with-resources（JDK 7+）。它会自动、安全地关闭资源，代码更短，也没有手写finally的这些坑：

// 最推荐：try-with-resources 自动关闭，无需手写 finallypublicintbest()throwsException{try(Resourcer=open()){returnr.process();}}

如果确实需要在清理阶段处理异常，也应该在finally里try-catch住并记录日志，而不是让它中断主流程或吞掉主异常。

四、常见误区与面试高频问答

Q：finally一定会执行吗？

绝大多数情况会，包括try里有return、break、continue、抛异常时。唯二的例外：一是执行到System.exit()直接终止 JVM；二是线程被强制杀死或断电这类极端情况。正常代码里，可以认为"finally必定执行"。

Q：try有return、finally也有return，最终返回哪个？

finally的。finally里的return会覆盖try（或catch）里的return，并丢弃待抛的异常。正因如此，别在finally里写return。

Q：为什么finally改了变量，返回值没变？

因为return x在执行时就把x的值复制到返回值暂存位置了，返回的是那个副本。finally里改x改的是变量本身，和已经复制出去的返回值无关。（返回对象引用时，改对象内部属性会生效，改引用指向不生效。）

Q：finally里抛异常会怎样？

如果try里也抛了异常，finally里的新异常会覆盖掉try里的原始异常向上抛出——原始异常（往往是更关键的那个）就丢了。所以finally里的代码也要保证不抛异常，或自己try-catch处理掉。

总结

try-finally遇上return和异常，几个容易被忽略的点：

try里的return会先把返回值暂存，再执行finally，最后返回暂存的值——所以finally改局部变量，改不动已经暂存的返回值。
finally里如果有return或throw，会截胡：覆盖try的返回值、并吞掉try中正在传播的异常——这是异常凭空消失的元凶。
正解：finally只做清理，不写return、不抛异常、不改返回变量；关资源优先用try-with-resources。