finally块不触发、传播或修改中断状态，仅保障清理逻辑执行；它看到的是当前真实中断状态，自身不做隐式操作；在finally中调用interrupt()会干扰中断意图，应避免。
finally块本身不触发、不传播、也不应主动修改线程中断状态，它的核心作用是保障清理逻辑执行——无论线程是否被中断、是否抛出异常、是否正常结束。
finally块不会自动恢复或清除中断状态
调用Thread.interrupt()后，线程中断标志被设为true；若之后在try块中发生了InterruptedException（如sleep()被中断），该异常抛出时会**自动清空中断状态**（变为false）。但finally块执行时，这个清除已经完成，它看到的是当前真实的中断状态——可能是false（刚被清空），也可能是true（之前被设过且未被阻塞方法干扰）。finally本身对中断标志不做任何隐式操作。
在finally中调用interrupt()是危险操作
不要在finally块里写Thread.currentThread().interrupt()。原因有二：
- 如果中断状态本已被清空（比如刚处理完
InterruptedException），强行重置会掩盖真实意图，让上层误判线程仍需响应中断； - 如果中断状态本来就是
true（例如非阻塞路径下手动检查后决定退出），再调一次interrupt()属于冗余，还可能干扰后续逻辑对中断状态的判断。
finally适合做资源清理，而非中断管理
中断是协作信号，清理是确定性责任。把二者职责分开更清晰：
- 在
catch (InterruptedException e)中：优先恢复中断状态（Thread.currentThread().interrupt()），再做必要清理，然后返回或抛出； - 在
finally中：只做关闭流、释放锁、注销监听器等与中断无关的确定性收尾工作； - 示例中
"清理资源"打印放在finally是对的，但“是否被中断”“要不要再中断”这些决策不应在此发生。
阻塞方法退出后，finally仍按序执行
即使sleep()、wait()或take()因中断抛出异常，JVM保证finally一定会执行——这是Java异常处理机制的底层保障。这意味着，哪怕线程正因中断而快速退出，你注册在finally里的文件句柄关闭、数据库连接释放等动作仍能可靠运行，避免资源泄漏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
