std::function+mutex不足以构成线程安全委托，因其无法保证订阅/取消订阅的原子性，且回调中修改委托易致死锁或迭代器失效；需分离调用期与变更期并发控制。
为什么 std::function + mutex 不足以构成线程安全委托？
直接用 std::function 包裹回调，再套一层 std::mutex 保护调用，看似可行，但会掩盖两个关键问题：一是订阅/取消订阅（operator+= / operator-=）本身需原子性，二是多个线程同时触发事件时，若回调内部又去修改同一委托实例（比如在回调里调用 unsubscribe()），会导致死锁或迭代器失效。真正的线程安全委托必须把「调用期」和「变更期」的并发控制拆开设计。
用 shared_ptr + weak_ptr 实现无锁订阅管理
核心思路是把所有注册的回调存进一个 std::vector<:shared_ptr>>></:shared_ptr>，每次添加用 std::make_shared 创建新节点；调用时遍历并用 weak_ptr::lock() 检查是否仍有效。这样增删操作只需保护容器本身（用 std::shared_mutex 更高效），而调用过程完全无锁——避免了临界区过长导致的吞吐下降。
class thread_safe_delegate {
mutable std::shared_mutex mtx_;
std::vector<std::shared_ptr<std::function<void()>>> callbacks_;
public:
void operator+=(std::function<void()> cb) {
std::unique_lock lock(mtx_);
callbacks_.push_back(std::make_shared<std::function<void()>>(std::move(cb)));
}
void operator-=(const std::function<void()>& cb) {
std::unique_lock lock(mtx_);
callbacks_.erase(
std::remove_if(callbacks_.begin(), callbacks_.end(),
[&cb](const auto& ptr) {
return ptr && *ptr == cb;
}),
callbacks_.end()
);
}
void invoke() const {
std::shared_lock lock(mtx_);
for (auto& ptr : callbacks_) {
if (auto cb = ptr.lock()) { // 避免 dangling call
(*cb)();
}
}
}
};
std::function 的相等比较不可靠，慎用 operator-=
std::function::operator== 在标准中未定义行为，GCC/Clang 下可能返回 false 即使逻辑相同。实际项目中应改用 token 或 handle 机制来取消订阅：
- 注册时返回唯一
size_tid 或std::anytoken - 内部用
std::unordered_map存储 id →std::shared_ptr -
operator-=改为unsubscribe(size_t id)，避免依赖std::function比较 - 若需支持 lambda 捕获对象生命周期绑定，必须确保该对象比委托存活更久，否则
weak_ptr::lock()会失败
信号量级事件系统要警惕 ABA 和内存重排
当委托被频繁增删且调用密集时，仅靠 std::shared_mutex 不足以防止 ABA 问题（如：A 线程读取 size=3 → B 删除1个 → C 添加1个 → size 又变回3 → A 误认为结构未变）。更健壮的做法是引入版本号（std::atomic<uint64_t></uint64_t>）配合读写锁，每次变更递增；调用前记录当前版本，遍历时发现不一致则重试。另外，所有共享数据访问必须加 memory_order_acquire/release 标记，否则编译器或 CPU 可能重排指令导致看到部分构造的对象。
立即学习“C++免费学习笔记（深入）”；
真正难的不是“怎么调用”，而是“谁负责销毁”和“何时算安全销毁”——尤其在跨线程传递回调时，务必明确所有权转移语义。
