守护线程必须独立、非阻塞、带生命周期管理：用scheduledexecutorservice启动，设daemon=true，atomicboolean控制启停，初始延迟0，固定间隔调度，线程名带业务标识。
在分布式系统中，用守护线程异步探活下游服务节点，核心不是“轮着问一遍”，而是“并发查、隔离错、快反馈”。它不依赖中心化注册中心的推送，适合轻量级或混合架构场景，比如边缘节点自检、本地服务网格健康兜底、或作为 etcd/Consul 心跳的补充验证层。
守护线程怎么启动才真正“守得住”
守护线程必须是独立、非阻塞、带生命周期管理的后台任务：
- 用 ScheduledExecutorService 启动（别用 Timer 或裸 Thread），支持异常捕获和线程复用
- 设置为 daemon=true，避免阻塞 JVM 退出；但需配合 AtomicBoolean running 主动控制启停
- 初始延迟设为 0，首次检查立即触发；后续按固定间隔（如 5 秒）重复调度
- 线程名建议带业务标识，例如
"health-probe-downstream"，便于日志追踪和线程 dump 分析
异步并行探活的关键实现逻辑
一次探活要覆盖多个下游节点，不能串行等待。关键在于把“发请求→等响应→判结果”拆成非阻塞操作：
- 对每个目标节点，提交一个 Callable
到线程池，返回 Future - 统一设置超时（如 2 秒），用
future.get(2, TimeUnit.SECONDS)避免单个节点拖垮整轮检测 - 用 CompletableFuture.allOf() 或 invokeAll() 批量等待，但注意：失败一个不影响其余执行
- 探活方式优先选轻量协议：HTTP HEAD /health、TCP connect + write/read 协议头、或 gRPC 的
HealthCheckService
健康判定与状态隔离怎么做
只看“连得上”或“返回 200”远远不够。真实场景中要区分三类失败：
-
网络层失败（ConnectException / TimeoutException）：标记节点为
UNREACHABLE，触发快速剔除 -
业务层失败（HTTP 5xx / 自定义错误码）：记录为
UNHEALTHY，可降权但暂不剔除 -
响应异常（空响应、解析失败、字段缺失）：视为数据污染风险，记
INVALID，连续 2 次则升级为 UNHEALTHY
所有状态变更写入 ConcurrentHashMap
异常不传播、失败不中断
守护线程最怕“一错全停”。必须做到单点失败完全隔离：
- 每个节点探测逻辑必须包裹 try-catch，捕获所有 Throwable（包括 OOM、StackOverflowError 以外的运行时异常）
- 探测任务内部不抛出异常给调度器，而是统一返回
ProbeResult.failed(e) - 调度器自身异常（如线程池满、OOM）要记录 ERROR 日志，并尝试重建 ScheduledExecutorService
- 允许配置最大连续失败次数（如 5 次），超过后自动暂停本轮探测，休眠 30 秒再恢复
