“僵尸句柄”指设备或平台异常退出后未释放的资源（如串口、mqtt实例等），长期占位耗尽系统资源；需通过自动关闭资源（注册+定时回收）与滑动窗口（动态活跃度建模）协同实现时效感知的生命周期闭环。
在千万级物联网场景中，“僵尸句柄”不是指网络连接断开后残留的 TCP 连接，而是设备端或平台侧因异常退出、未释放资源（如文件描述符、串口句柄、MQTT 客户端实例、内存缓冲区）导致的长期占用。这类句柄不主动通信却持续占位，会逐步耗尽系统资源，引发设备离线、消息积压甚至服务崩溃。自动关闭资源 + 滑动窗口不是简单叠加两个概念，而是构建一个带时效感知的资源生命周期闭环。
自动关闭资源：从“申请即持有”转向“按需即租用”
嵌入式设备或边缘网关常因异常重启、任务卡死、回调未触发等原因，跳过资源释放逻辑。必须打破“malloc/open 后靠代码路径保证 free/close”的脆弱依赖：
- 所有关键资源（如串口句柄、TLS socket、传感器驱动实例）统一注册到一个轻量级资源管理器，绑定创建时间戳和预期存活时长（例如：MQTT 连接默认 5 分钟无心跳即标记为可疑）
- 资源管理器内置定时扫描器，每 30 秒遍历一次注册表，对超时未刷新活跃状态的资源执行强制回收（close + 置空指针）
- 对不可中断的底层资源（如硬件 DMA 缓冲区），采用“软关闭”策略：先禁用数据流、清空 FIFO、标记为 pending release，待下一次调度周期再完成物理释放
滑动窗口：为资源活跃度建模，识别真实僵尸
固定时间窗口（如“10 分钟内无任何上报”）容易误杀休眠设备；滑动窗口则动态跟踪最近 N 秒内的行为密度，更贴近设备真实运行节律：
- 为每个设备连接维护一个 60 秒滑动窗口，记录其心跳、属性上报、命令响应等事件的时间戳
- 窗口内事件数低于阈值（如 ≤2 次），且最近一次事件距今超过窗口长度的 1.5 倍（即 ≥90 秒无活动），则触发“疑似僵尸”标记
- 连续两次滑动窗口检测均命中该条件，才升级为“确认僵尸”，交由资源管理器执行关闭流程
千万级落地的关键协同点
单台边缘节点或云服务实例无法承担千万设备的全量滑动窗口计算。需分层收敛：
- 设备端轻量实现：MCU 级仅维护 3 个最近心跳时间戳，通过差值估算活跃度，满足低功耗要求
- 边缘网关聚合：对下属数百设备做本地滑动窗口统计（如每 10 秒滚动计算一次“过去 60 秒平均上报频次”），只向上游上报异常趋势，而非原始时间戳
- 云端分级处置：IoT Hub 或自建接入层接收聚合指标，对“连续 3 个周期上报频次下降 >80%”的设备组，下发指令触发边缘侧强制重连与句柄重建
避免常见陷阱
滑动窗口本身不解决资源泄漏，它只是判断依据。真正起效的是后续动作是否可靠：
- 不能仅 close 句柄就结束——需同步清除关联的订阅关系、定时器、回调函数指针，否则可能引发野指针访问
- 滑动窗口时间粒度要匹配业务：温湿度传感器可设 60 秒窗口，而工业振动传感器采样率达 kHz，窗口应压缩至 5 秒以内
- 自动关闭必须可逆：首次关闭后若设备突然恢复上报，应允许快速重建资源并恢复服务，而非直接拉黑
