显式绑定负载均衡销毁引发内存泄漏，本质是资源生命周期与调度逻辑脱节——销毁未同步清理文档状态快照、协作锁、增量缓冲区等关联内存上下文，导致悬挂引用和内存滞留。
显式绑定负载均衡销毁引发的内存泄漏，本质是资源生命周期与调度逻辑脱节所致——当负载均衡器主动销毁某节点连接或会话时，若未同步清理其关联的内存上下文（如文档状态快照、协作锁对象、增量变更缓冲区），就会导致跨进程/跨节点的悬挂引用和内存滞留。
确认销毁路径是否覆盖全部资源持有者
分布式协作文档系统中，一个用户会话常被多层组件引用：前端长连接、后端协作服务实例、分布式锁管理器、变更广播通道、本地内存缓存。显式销毁操作若只调用负载均衡器的“下线节点”接口，而未触发级联释放，就会漏掉深层依赖。
- 检查销毁流程是否包含对
DocumentSessionManager、CollabLockRegistry、DeltaBufferPool三类核心组件的显式清理调用 - 验证销毁前是否广播
SESSION_TERMINATE事件，并确保所有监听方完成异步清理（如延迟100ms再释放共享内存段） - 避免仅靠GC等待回收——协作状态对象通常持有多节点间弱引用或跨进程句柄，GC无法感知其逻辑生命周期
用RAII模式封装协作资源生命周期
将文档协作上下文（如DocCollabContext）设计为作用域绑定对象，其构造时注册到全局资源注册表，析构时自动触发反向清理链。关键在于销毁时机必须与负载均衡决策强同步。
- 在负载均衡器执行
removeNode(nodeId)前，先调用contextManager.gracefulShutdown(nodeId)，该方法阻塞直至所有相关DocCollabContext完成析构 - 每个
DocCollabContext内部维护std::shared_ptr引用计数，但额外引入lease_token机制：销毁命令下发后，token失效，后续任何访问立即返回错误而非延长生命周期 - 对共享内存段（如用于OT算法的delta buffer）使用
mmap + MADV_DONTNEED显式通知内核释放物理页，不依赖munmap延后回收
监控销毁动作与内存残留的因果链
单纯看内存增长曲线无法定位“销毁泄漏”，需建立销毁事件与内存对象存活的追踪映射。
- 为每次销毁操作生成唯一
destroy_id，在所有关联资源（锁、buffer、session）中标记该ID；运行时定期扫描未清除标记的资源，输出destroy_id → 残留对象类型 → 节点地址报告 - 利用eBPF工具（如
bpftrace）捕获close()、munmap()系统调用失败日志，重点排查因文件描述符泄漏导致的socket buffer无法释放问题 - 在测试阶段注入“强制销毁”故障：随机选择活跃节点触发销毁，5秒后用
gcore生成core dump，用gdb检查DocumentState*实例是否仍被WorkerThreadLocal或GlobalBroadcastQueue持有
规避常见销毁陷阱
很多泄漏并非代码缺陷，而是销毁逻辑与分布式状态不一致造成的假性泄漏。
- 不要在销毁时直接
delete对象——改用deferred_deleter队列，在IO完成回调后安全释放，防止正在处理的OT操作引用被提前回收 - 避免销毁时清理Redis锁但遗漏本地内存锁（如
std::mutex未unlock）；建议统一用DistributedLockGuardRAII包装，构造时加锁，析构时自动释放双端 - 注意时钟漂移影响：若节点A判定节点B已销毁，但B因网络延迟仍在发送心跳，其本地缓存可能持续写入，需在销毁确认阶段加入
quorum-based lease expiration机制
