条件流程控制不能直接防止句柄泄漏，但通过将资源生命周期与线程状态、中断信号、业务分支显式绑定，确保每条退出路径都释放资源，从而显著降低泄漏概率。
条件流程控制本身不能直接“防止”句柄泄漏，但它能显著降低泄漏发生概率——关键在于把资源生命周期与线程状态、中断信号、业务逻辑分支显式绑定，让释放动作不依赖线程自然结束，而由可控的判断路径触发。
用中断状态驱动资源清理路径
长周期 RUNNABLE 线程常因阻塞调用（如 socket.read()、queue.take()）或无限循环卡住，导致 finally 块无法执行。此时需将中断检查嵌入主循环，并在退出前强制释放：
- 每次循环开头检查 Thread.interrupted()，若为 true 则主动 break 并进入清理段
- 阻塞方法（如 Object.wait()、LockSupport.park()）被中断后会抛出 InterruptedException，必须捕获并设置退出标志，而非仅打印日志
- 避免仅靠“任务完成”作为唯一退出条件；增加超时、计数、外部信号等多路退出条件，确保总有路径走到 close() 步骤
在关键分支中强制封装可关闭资源
不是所有代码路径都走同一段 finally；若业务逻辑存在 if/else 或 switch 分支，每个可能提前返回的分支都应包含资源释放逻辑：
- 优先使用 try-with-resources，它在任意分支 return、throw 或正常结束时都会触发 close()
- 若需跨分支复用资源（如一个 Socket 被多个处理逻辑共用），用布尔标记记录是否已关闭，避免重复 close() 异常，也防止遗漏
- 对非 AutoCloseable 资源（如 AWT Graphics、JNI GlobalRef），在每个分支末尾显式调用 dispose() / DeleteGlobalRef()
用状态机替代裸 while(true)
把线程行为建模为有限状态机（如 IDLE → CONNECTING → PROCESSING → CLOSING），每个状态转移都受条件约束，并在进入 CLOSING 状态时统一执行清理：
- 状态变量用 volatile 或 AtomicBoolean 保证可见性，避免因缓存导致状态未更新而跳过清理
- 状态变更与资源操作耦合：例如从 PROCESSING 进入 CLOSING 时，同步关闭 input stream、cancel heartbeat timer、释放 native buffer
- 状态机主循环中，任何异常或中断都导向 CLOSING，而不是吞掉异常继续运行
结合定时与事件双重退出条件
单一条件易失效（如只等某个 flag 为 true，但 flag 永远不置位）；叠加时间维度和外部事件可提高鲁棒性：
- 每轮循环检查 “是否超时 + 是否收到 shutdown 信号 + 是否任务队列为空”，任一为真即准备退出
- 对网络监听线程，可设 idle timeout：连续 N 秒无新连接则主动 close ServerSocket 并终止
- 利用 ScheduledExecutorService 提交“看门狗任务”，定期扫描当前线程持有的资源数，超过阈值则触发 self-interrupt
不复杂但容易忽略：条件流程不是写得越多越安全，而是每条路径都要回答“这里出错/退出，资源还在吗？”——答案必须是“已释放”或“有兜底机制”。
