finally在重试循环中每次迭代都执行，执行时机与次数取决于try位置；finally中return会终止重试；资源清理需匹配重试粒度，推荐try-with-resources或独立资源新建+关闭。
在重试循环中使用 finally，关键不是“它会不会执行”，而是“它在每次迭代中何时执行、执行几次、以及是否干扰重试逻辑”。理解清楚这三点，才能避免资源重复释放、状态错乱或重试失效。
重试循环里，finally 每次都会执行
只要 try 块开始执行，无论循环是用 break 退出、continue 跳过本次、还是 return 提前结束方法，对应的 finally 都会执行。在重试场景下，这意味着：
- 如果
try写在for或while循环体内，每次循环迭代都触发一次finally - 如果
try包裹整个循环（比如try { while(...) { ... } }），那finally只在循环彻底结束后执行一次 - 常见写法是把
try-finally放进循环体，确保每次尝试失败后都能清理临时资源（如 HTTP 连接、临时文件句柄）
finally 中的 return 会直接终止重试
这是最容易踩的坑。一旦 finally 里写了 return，它不仅覆盖 try/catch 的返回值，还会让整个方法立刻退出——重试循环根本不会继续。
- 示例：
try { callApi(); } catch (IOException e) { delay(); continue; } finally { return "done"; }→ 第一次失败后，continue失效，方法直接返回 - IDE（如 IntelliJ）通常会高亮警告，因为语义冲突：你写重试逻辑，却在清理块里强行退出
- 正确做法：清理归清理，控制流归控制流；把
return移到循环外，或仅在最终成功时返回
资源清理要匹配重试粒度
重试时资源的状态必须可重入。如果 finally 关闭了某个共享连接，而下次重试又试图复用它，就会抛 IllegalStateException。
立即学习“Java免费学习笔记（深入）”；
- 推荐模式：每次重试都新建独立资源（如新创建
HttpClient实例），并在对应finally中关闭 - 若复用资源（如连接池），
finally不应关闭它，而应归还或标记为可用；关闭动作留给整个重试流程结束之后 - Java 7+ 更稳妥的方式是用
try-with-resources管理单次尝试的资源，比手动finally更清晰、不易遗漏
异常未被捕获时，finally 仍执行但重试可能失效
如果重试循环中 try 抛出异常，但没有 catch 捕获（比如声明了 throws），那么异常会向上抛出，但 finally 仍会在抛出前执行。
- 此时重试机制本身已中断，
finally只负责当次尝试的收尾，不再参与后续重试 - 若希望异常也纳入重试策略，必须显式
catch并判断是否重试，不能依赖未捕获异常自动重试 - 注意运行时异常（如
NullPointerException）默认不被检查，容易漏写catch，导致重试逻辑静默失效
