Lambda本身无法感知断电断网，真正导致线程挂起的根源是外部线程被未设超时的IO或网络操作阻塞；必须通过显式超时、非阻塞回调、可中断异步原语及线程池隔离等手段切断等待链，避免无限等待。
系统断电、断网这类极限异常不是 Lambda 本身能感知或响应的，真正挂起和饥饿的根源在于：外部线程（比如主线程、IO线程、线程池线程）被 Lambda 所在的异步操作阻塞等待，而该操作又因底层资源失效（如 socket 断连未及时触发超时、NIO channel 卡在不可中断的 native 调用）迟迟无法完成或抛出异常。
关键不是“保护 Lambda”，而是切断等待链
Lambda 只是执行载体，问题出在它所依赖的同步等待机制或未设限的异步调用上。必须让外部线程不陷入“无限等一个永远不会回来的结果”状态。
- 所有涉及 IO、网络、外部服务的调用，必须显式设置超时（timeout），且超时逻辑需在 调用发起侧 控制，不能依赖下游被动通知。例如：
CompletableFuture.orTimeout(5, TimeUnit.SECONDS)或HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(3)) - 避免在 Lambda 中直接调用
.get()、.join()、.wait()等阻塞方法；改用thenApply、handle、exceptionally等非阻塞回调链 - 对可能长期卡住的 native 操作（如某些 JNI 封装的硬件访问、旧版驱动接口），用
Thread.interrupt()+ 定时 watchdog 线程双重兜底，而非依赖单一线程等待
用可中断的异步原语替代隐式等待
传统 Future.get() 在底层 socket 断开但 TCP FIN 未送达时，可能卡住数十秒甚至更久。Java 19+ 的 StructuredTaskScope 或手动封装的可中断 VirtualThread 能主动中止整个子任务树。
- 优先使用
CompletableFuture.supplyAsync(..., executor)并配合orTimeout+exceptionally，确保超时后立即释放线程 - 若必须同步等待结果（极少数场景），改用
LockSupport.parkNanos自旋+轮询方式检测中断/超时，而非无条件挂起 - 对 HTTP、DB 等客户端，禁用默认的“无限重试”和“无连接超时”，强制配置
readTimeout、writeTimeout、connectionTimeout
隔离与降级：不让一个失败拖垮全局线程池
断电断网常引发连锁故障。若所有任务共用同一套线程池，一个慢请求会吃光全部线程，导致新请求连入池机会都没有。
- 按业务重要性或资源类型拆分线程池（如：IO 密集型用
ForkJoinPool.commonPool()或专用ThreadPoolExecutor，CPU 密集型用固定大小池） - 在 Lambda 外层加熔断器（如 Resilience4j 的
CircuitBreaker），连续失败后快速失败，避免线程空耗在无效重试上 - 对关键路径（如支付、登录）启用“线程池保底数”：预留少量核心线程专供高优任务，即使池满也不抢占
硬件级异常的被动应对策略
断电无法被软件实时捕获，但断网、网卡掉线可通过 OS 层信号或驱动事件有限感知。
- 启用 TCP keepalive（
SO_KEEPALIVE）并调小间隔（如 30s），加速发现死连接 - 监听系统级网络事件（Linux 上通过
netlink或/proc/sys/net/ipv4/conf/*/arp_ignore变化），触发线程池主动清空待处理任务 - 对关键服务进程，配置 systemd 的
RestartSec=5+StartLimitIntervalSec=60，确保崩溃后快速重建上下文，而非靠旧线程硬扛
