finally块应仅执行关流、清threadlocal、置状态位三类轻量操作；塞入rpc、重试、日志上报等重职责会阻塞线程池、掩盖原始异常、破坏释放确定性，并与云原生异步解耦架构根本冲突。
finally块本该是轻量、确定、无依赖的“收尾守门人”，一旦被塞进太多职责，就会从资源清理工具蜕变为系统稳定性的隐形破坏者。它不直接崩溃程序，却会层层放大故障传播路径，让原本局部的问题演变成架构级雪崩。
阻塞线程池，拖垮整个服务吞吐
当finally中发起同步RPC、数据库写入或HTTP调用，这些操作天然带网络延迟和不确定性。而finally没有超时控制、无法异步隔离——一个5秒卡住的上报日志，就可能让一个Web容器线程持续占用；在线程池固定为200的场景下，10个并发失败请求就能吃掉全部线程，后续请求只能排队或被拒绝。更危险的是，这类阻塞不会立刻报错，而是静默地把系统拖入“高延迟、低吞吐、连接堆积”的亚健康状态。
掩盖原始异常，让故障定位失去上下文
try里抛出“订单库存扣减失败”，finally里又因连接池已满抛出“DataSource close failed”——JVM只会把后者作为最终异常向上抛出。监控看到的全是“资源释放异常”，真实业务问题被彻底掩埋。运维查日志、开发看堆栈、SRE做根因分析，全在错误的方向上消耗精力。这种异常覆盖不是偶发bug，而是JVM规范定义的行为，只要finally抛异常，原始异常就物理性丢失。
破坏资源释放的确定性语义
finally的设计契约是“一定执行、快速完成”。但若在里面加重试逻辑、本地文件落盘、MQ重发、甚至new Thread()，就等于把“确定性收尾”变成了“不确定任务调度”。比如：重试三次失败后写本地磁盘，磁盘满则IO异常；磁盘正常但文件句柄泄漏；句柄正常但日志轮转策略缺失导致占满磁盘……每一层都引入新失败点，而这些失败又反过来干扰真正的资源释放（如数据库连接close()本身被延迟或跳过）。
与现代架构模式产生根本性冲突
云原生、微服务、事件驱动等架构强调解耦、异步、失败容忍。而重量化的finally恰恰反其道而行之：它强制同步等待、强依赖下游、拒绝降级、无法水平伸缩。例如，在K8s滚动发布时，一个卡在finally里的线程可能阻止Pod优雅退出；在Serverless环境中，它可能导致函数超时被平台强制终止，且无任何补偿机制。这种代码风格与弹性设计原则完全背道而驰。
本质上，finally不是功能扩展区，而是安全边界。越把它当“万能钩子”，系统就越脆弱。真正健壮的架构，是把所有对外交互移出去，让finally只做三件事：关流、清ThreadLocal、置状态位。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
