会，finally 在 return 之后仍执行，但不改变已确定的返回值；System.exit() 会跳过 finally；try-with-resources 可安全替代 finally；finally 抛异常会覆盖主异常。
finally 在 return 之后还会执行吗
会。只要 try 或 catch 块中出现了 return，finally 仍会在方法真正返回前执行——但注意：它不会改变已确定的返回值（基本类型或不可变引用），除非 finally 自己也写 return。
常见错误现象：
• 写了 return 后以为流程结束了，结果 finally 里的日志没打、资源没关；
• 在 finally 里又写 return，导致 try 中的返回值被覆盖（编译器不报错，但逻辑出错）。
实操建议：
• 不要在 finally 中使用 return，否则会屏蔽异常和原始返回值；
• 若需修改返回逻辑，应把计算移到 try 内完成，finally 只做清理；
• 对于对象引用（如 StringBuilder），finally 中修改其内容会影响返回结果（因为是同一对象）。
public static String test() {
StringBuilder sb = new StringBuilder("hello");
try {
return sb.append("-try").toString(); // 返回 "hello-try"
} finally {
sb.append("-finally"); // 此时 sb 变成 "hello-try-finally"
// 但已返回的字符串不受影响
}
}
finally 会不会在 System.exit() 后执行
不会。System.exit(int) 会立即终止 JVM，绕过所有未执行的 finally 块。
立即学习“Java免费学习笔记（深入）”；
使用场景：
• 主程序启动失败时调用 System.exit(1)；
• 单元测试中误用 System.exit 导致资源泄漏、测试卡死。
实操建议：
• 避免在业务逻辑中直接调用 System.exit()；
• 若必须退出，先手动清理关键资源（如关闭数据库连接池），再调用 System.exit()；
• 在测试中可用 SecurityManager 拦截 System.exit() 调用，防止意外终止。
try-with-resources 能替代 finally 吗
能，且更安全。Java 7 引入的 try-with-resources 语句会自动调用 AutoCloseable.close()，等价于显式写在 finally 中，但无需手动判断 null 和捕获 close() 异常。
参数差异：
• try-with-resources 要求资源类实现 AutoCloseable（如 FileInputStream、Connection）；
• 它在 try 块结束时（无论是否异常）自动关闭，且多个资源按声明逆序关闭；
• 如果 close() 抛异常，会被抑制（suppressed），可通过 Throwable.getSuppressed() 获取。
性能 / 兼容性影响：
• 字节码层面比手写 finally 多一点开销（主要是异常压制机制），但可忽略；
• Java 7+ 才支持，老项目升级需确认 JDK 版本。
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
return br.readLine();
} // fis 和 br 的 close() 自动在此处调用
finally 中抛异常会怎样
如果 try 或 catch 已经抛出异常，而 finally 也抛异常，则 finally 的异常会“吃掉”前面的异常（即原始异常丢失），仅向外传播 finally 的异常。
容易踩的坑：
• 在 finally 中调用可能抛异常的方法（如 conn.close()），却不捕获处理；
• 日志框架配置错误导致 logger.error() 内部抛 NullPointerException，掩盖了原始业务异常。
实操建议：
• finally 中所有可能抛异常的操作都应包裹在 try-catch 内；
• 关键清理操作（如解锁、回滚事务）失败时，应记录警告日志，而非抛异常；
• 使用 try-with-resources 可规避大部分此类问题，因它的 close() 异常默认被抑制而非覆盖主异常。
复杂点在于：异常压制机制只在 try-with-resources 中默认启用；手写 finally 时若想保留原始异常，必须手动调用 addSuppressed()，这点极易被忽略。
