C++中使用std::ref传递shared_ptr到回调是否安全？

你当前的实现存在明确的未定义行为风险，远不是内存泄漏层面的问题，用std::ref包裹栈上shared_ptr传入长期保存的回调完全不安全。

风险来源拆解 #

• std::ref的本质是生成一个轻量的std::reference_wrapper实例，内部仅存储指向原对象的指针，不会延长被引用对象的生命周期，也不会拷贝原对象。
• 你在handle函数中创建的context是栈上的局部shared_ptr<Connection>变量，当你用std::ref(context)将其绑定到回调时，生成的回调对象仅持有一个指向栈上context的指针。一旦handle函数执行完毕返回，栈上的context变量就会被销毁，回调内部存储的指针立刻成为悬垂引用。
• 绝大多数网络库的onMessage回调都是跨线程、跨事件循环延迟触发的长期保存对象，只要这类回调不是在handle函数的栈帧内同步执行完成，后续真正触发回调时，解引用这个悬垂引用就会触发段错误、内存踩踏等未定义行为。

常见认知误区澄清 #

你之前查到的“对shared_ptr使用引用传递会引发内存泄漏”的说法存在明显的场景混淆：

• 循环引用导致的内存泄漏，和传值还是传引用没有任何关系；你当前场景下的风险甚至比内存泄漏更严重——是悬垂引用导致的即时崩溃。
• 如果你不使用std::ref，直接按值传递shared_ptr，相当于让回调对象持有一份shared_ptr的拷贝，这会让引用计数+1，根本不会引发泄漏，反而能保证只要回调存活，关联的Connection对象就不会被提前从unordered_map中删除。

适配你场景的安全实现方案 #

• 针对你提到的“上下文对象统一存在unordered_map中、断连时会被移除”的场景，直接移除bind中的std::ref，按值传递context即可：

  void HTTPTransport::handle(const evpp::TCPConnPtr &socket, std::shared_ptr<Connection> context) {
      // 去掉std::ref，直接把socket、context按值绑定，让回调自行持有副本
      ws->onMessage(std::bind(&HTTPTransport::handleMessage, this, socket, context, _1));
  }
  

• 按值传递shared_ptr带来的开销仅为一次原子引用计数的增减，和网络收发的IO开销相比完全可以忽略，没必要为了这部分微优化引入生命周期风险。
• 针对你提到的“context可能为空”的情况，只需要在handleMessage入口增加空判断即可，完全不影响安全性：

  void HTTPTransport::handleMessage(const evpp::TCPConnPtr &socket, std::shared_ptr<Connection> context,
                                    const std::variant<int, std::string> &message) {
      // 空shared_ptr直接跳过逻辑即可，不会触发任何内存问题
      if (!context) return;
      auto ctx = context->get();
      // 业务逻辑
  }
  

• 如果你确实需要极致优化、不想增加shared_ptr的引用计数开销，必须明确保证回调的生命周期严格短于handle函数的栈帧（也就是回调一定在handle返回前同步执行完），那也不需要用std::ref，直接把handleMessage的参数改成const std::shared_ptr<Connection>&，bind时直接传原变量即可——这种场景下bind会自动为引用类型参数存储引用，效果和用std::ref完全一致，但语义更清晰。

内容的提问来源于stack exchange，提问作者jeffbRTC