守护线程需用try-catch-finally确保异常后自动恢复、资源不泄漏、不静默失联；捕获具体异常并分级处理，finally仅用于清理与心跳保活，禁throw/return；外层while(true)内嵌try-catch-finally，配合sleep与中断检查，并优先使用try-with-resources管理资源。
用 try-catch-finally 包裹守护线程的死循环，核心不是让线程“不崩溃”，而是确保它在异常后能**自动恢复运行、不泄漏资源、不静默失联**——这对分布式集群的长期稳定性至关重要。
捕获具体异常，避免吞掉关键信号
守护线程常执行心跳上报、状态同步、定时拉取等任务，抛出的异常类型高度可预期。不能只写 catch (Exception e)：
- 网络中断、超时 → 捕获
IOException、TimeoutException，记录 warn 日志并重试 - ZooKeeper/Kafka 连接断开 → 捕获对应客户端异常（如
KeeperException），触发重连逻辑 - 序列化失败、配置解析错误 → 捕获
JsonProcessingException或IllegalArgumentException，降级为默认值或跳过单条数据 - 所有 catch 块必须按「子类在前、父类在后」排列，否则
NullPointerException可能被泛化的RuntimeException提前截获
finally 不用于恢复，而用于强制清理与心跳保活
守护线程里 rarely 需要 finally 做“恢复”，但极需它做两件事：
- 关闭临时打开的资源：比如某次心跳用到的 HTTP 连接、临时文件流、本地缓存锁，即使处理中途异常也必须释放
- 更新最后活跃时间戳或发送“我还在”的轻量心跳（如向本地健康检查端点写入时间戳），防止集群误判该节点失联
- 禁止在 finally 中 throw 新异常或写 return —— 否则会覆盖原异常，掩盖真实故障点
用 while(true) + 显式 sleep 控制节奏，别依赖 finally 跳转
典型结构应是「try 处理主逻辑 → catch 分类应对 → finally 清理收尾 → 循环继续」，而非把整个 while 包进 try：
- ✅ 推荐写法：外层 while(true)，内层 try-catch-finally 包裹单次任务执行
- ❌ 危险写法：把 while 放进 try，一旦 catch 后没 break/continue，可能跳过 sleep 导致 CPU 打满
- 每次循环末尾加可控 sleep（如
TimeUnit.SECONDS.sleep(5)），并在 sleep 前检查线程中断状态（Thread.interrupted()），支持优雅停机
比 finally 更稳：优先用 try-with-resources 管理短生命周期资源
如果守护线程中频繁创建 AutoCloseable 资源（如 HttpClient 实例、KafkaProducer、BufferedWriter），直接用 try-with-resources 替代手写 finally：
- 资源声明在 try() 括号内，无论是否异常、是否提前 return，close() 都会被调用
- 若 close() 自身抛异常，它会被“抑制”（suppressed），原始异常仍为主异常，可通过
e.getSuppressed()查看，不丢失上下文 - 示例：
try (CloseableHttpClient client = HttpClients.createDefault()) { ... }
