不能用裸指针管理路由表，因其无所有权语义、易致悬垂指针和内存泄漏；多线程下 delete 后仍访问会引发未定义行为；无法安全共享、不兼容标准容器；应改用 shared_ptr 或 unique_ptr+原子指针交换，并辅以原子操作或锁保障字段并发安全。
直接用裸指针管理路由表在高并发负载均衡器中是危险的，容易引发悬垂指针、内存泄漏和线程安全问题。现代C++负载均衡实现应避免 new/delete 手动管理路由表内存，转而使用 RAII 和智能指针组合控制生命周期。
为什么不能用 raw pointer 管理路由表
裸指针本身不携带所有权语义，无法自动释放资源；在多线程更新节点（如服务上下线）时，若一个线程刚 delete 了某节点数据，另一线程仍持有其 Node* 并尝试访问，就会触发未定义行为——常见现象是 core dump 或随机返回错误后端地址。
- 没有自动析构：路由表频繁增删时，
delete遗漏概率随代码路径增加而上升 - 无法共享所有权：健康检查模块、哈希环重建模块、请求分发模块都需要读取同一份节点数据，裸指针无法安全共享
- 与标准容器不兼容：例如
std::map<uint32_t node></uint32_t>中的Node*无法参与移动语义或异常安全清理
std::shared_ptr<node></node> 是更稳妥的选择
当多个模块（如一致性哈希环、最小连接数统计器、健康检查回调）需要同时持有对同一节点的引用时，std::shared_ptr<node></node> 能自然表达“共享所有权”，且在最后一个引用离开作用域时自动调用 Node 析构函数。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 构造节点时统一用
std::make_shared<node>(...)</node>，避免两次内存分配 - 哈希环可定义为
std::map<uint32_t std::shared_ptr>></uint32_t>，插入/查找都不影响节点生命周期 - 节点下线时，只需从所有容器中移除该
shared_ptr，无需显式delete - 注意循环引用风险：若
Node内部又持有指向自身所属负载均衡器的shared_ptr，需改用std::weak_ptr破解
高频读场景下考虑 std::unique_ptr + 原子指针交换
如果路由表只允许单点写入（如仅由服务发现模块更新），但被成千上万个请求线程并发读取，用 std::shared_ptr 的引用计数原子操作会成为性能瓶颈（实测在 100Gbps 流量下可引入 ~8% 的额外延迟）。此时更适合用 std::unique_ptr<routetable></routetable> 配合原子指针替换：
- 写入线程构建全新
RouteTable实例，填充好所有std::unique_ptr<node></node> - 用
std::atomic_store(&route_table_ptr, std::move(new_table))原子替换指针 - 读取线程通过
std::atomic_load(&route_table_ptr)获取当前快照，全程无锁、无引用计数开销 - 旧表内存由读线程在完成本次请求后自行释放（需配合 RCU 或 epoch-based reclamation）
容易被忽略的关键点
即使用了 shared_ptr，若 Node 对象内部含有非原子字段（如 int current_connections），多线程并发修改仍会导致数据竞争。必须明确区分：指针管理解决的是内存生命周期问题，而非并发读写一致性问题——后者仍需 std::atomic、细粒度锁或无锁结构配合。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
