不能直接用 std::map 或 vector 实现广播树，因其无法满足单点写入、多点低延迟扩散的核心诉求：std::map 插删触发红黑树重平衡，vector 频繁 realloc，均导致高并发下主线程阻塞；且二者不支持子树隔离更新与 O(1) 跳过断连节点。
为什么不能直接用 std::map 或 vector 实现广播树
广播树的核心诉求是「单点写入、多点低延迟扩散」，不是普通查找或遍历。用 std::map 存子节点会导致每次插入/删除都触发红黑树重平衡，vector 则在频繁增删时反复 realloc，两者都会在高并发写入场景下卡住主线程。更关键的是，它们不天然支持「子树隔离更新」——比如某个下游断连，你得遍历整个结构标记状态，而广播树需要局部失效、快速跳过。
用 std::unordered_set + 原生指针构建轻量级父子关系
真正高效的广播树底层只需要两个动作：快速添加子节点、O(1) 跳过已断开节点。推荐用 std::unordered_set 存子节点指针（不是值），配合原子状态位控制可达性：
- 每个节点持有
std::atomic，断连时只改这个位，不删指针active{true} - 广播时用
for (auto* child : children)遍历，循环内加if (!child->active.load(std::memory_order_acquire)) continue; - 子节点指针本身不参与内存管理，由上层统一生命周期控制（避免 shared_ptr 引用计数开销）
- 父节点不存子节点数据副本，只存指针；子节点可反向持父节点弱引用（
std::weak_ptr）用于主动注销
避免锁竞争：广播路径必须无锁，状态变更走 RCU 风格延迟回收
如果每次增删子节点都用 std::mutex，吞吐量立刻腰斩。正确做法是：
- 子节点注册走无锁队列（如
moodycamel::ConcurrentQueue），由专用线程批量刷入children集合 - 断连通知不立即修改
active，而是放入延迟队列，等当前正在广播的批次结束后再置 false - 内存回收不调用
delete，改用对象池（boost::object_pool或自定义 slab allocator）避免 malloc 争抢
树形结构实际只需两层：根节点 + 扇出叶节点
真实高性能场景中，95% 的广播树根本不需要深度嵌套。多层树会放大路径长度、增加缓存不命中率。典型部署是：
- 根节点聚合所有活跃连接（WebSocket / TCP session）
- 每个连接封装为一个叶节点，含发送缓冲区、写事件状态、心跳计时器
- 广播时对全部叶节点做向量化写（
writev或sendmmsg），一次系统调用发多个包 - 如需分组（如按 topic 过滤），用哈希表索引叶节点集合：
std::unordered_map<:string std::vector>>，但注意 map 本身不参与广播热路径
最易被忽略的一点：广播树的「性能瓶颈从来不在树结构本身，而在 socket 写缓冲区是否填满、是否触发 EAGAIN、以及内核发送队列是否堆积」。结构再快，没处理好 EPOLLOUT 事件驱动和零拷贝发送，照样卡死。先确保每个叶节点能异步写、失败可重试，再优化树形组织。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
