Lambda调用成员函数的C++技术疑问（Unreal Engine场景衍生）

代码示例 #

#include <iostream>
#include <functional>

// Basic class with a callback function expressed as a lambda calling a member function 
class Foo {
    private:
        int i = 0;
    public:
        Foo(int j){
            i = j;
        }

        // A member function that should be called by a manager
        void f(){
            std::cout << i << std::endl;
        }

        // Wrap the member function in a lambda
        std::function<void()> wrapper = [&](){f();}; // <---- What happens when object is destroyed before call? 
};

// Manager class which calls a specified function after some work 
class Manager {
    public:
        // A function that returns immediately and after some time calls the passed function
        void asyncWork(std::function<void()> callback){
            // Some work here...

            callback();
        } 
};

int main() {

    // Create object
    Foo foo(42);

    // Create manager
    Manager manager;

    // Pass the callback function to the manager
    manager.asyncWork(foo.wrapper);

    return 0; 
}

程序执行逻辑 #

1. 创建一个简单对象，其通过std::function封装成员函数调用（在Unreal Engine中对应使用TFunction<>类型）；
2. 将该封装后的函数作为回调传递给管理器类；
3. 一段时间后回调触发，但原对象可能已不存在。

1. 如何确保原对象销毁后回调不会执行？ #

• 用智能指针绑定生命周期：让Foo继承std::enable_shared_from_this，lambda里捕获对象的weak_ptr来检测存活状态，确认对象还在再执行成员函数：

  class Foo : public std::enable_shared_from_this<Foo> {
      // ...
      std::function<void()> wrapper = [self = weak_from_this()](){
          if(auto aliveObj = self.lock()){
              aliveObj->f();
          }
      };
  };
  

  要是用shared_ptr捕获，只要回调存在，对象就不会被销毁，适合需要确保回调一定执行的场景。
• 手动注销回调：给Foo添加析构函数，对象销毁时通知Manager移除对应的回调。比如让Manager维护一个可修改的回调列表，Foo构造时注册回调，析构时调用Manager的移除接口。
• 存活标记（慎用）：在Foo中添加原子布尔变量isAlive，构造时设为true，析构时设为false。lambda执行前先检查标记：

  class Foo {
      std::atomic<bool> isAlive = true;
      // ...
      std::function<void()> wrapper = [&](){
          if(isAlive) f();
      };
      ~Foo() { isAlive = false; }
  };
  

  这种方式存在竞态风险，若对象内存已被回收，访问标记位仍会导致非法操作，优先级低于智能指针方案。

2. 这种Lambda封装成员函数的方式性能开销大吗？ #

• 绝大多数场景下开销可忽略：std::function的调用仅为一次间接跳转，和函数指针的开销接近。lambda本身是轻量封装，不会带来额外的沉重负担，仅在每秒调用数十万次的极端性能敏感场景（如游戏核心循环）可能需要优化。
• 对比直接调用成员函数：确实多了一层std::function的调度，但现代编译器的内联优化会尽可能消除这部分开销。若使用Unreal Engine的TFunction，其实现比标准库std::function更轻量化，开销会更小。
• 潜在开销点：主要是std::function构造时的拷贝/移动操作，若lambda捕获的内容较大，可能触发堆分配。但当前示例中lambda捕获的是引用，无需堆分配，开销极低。

3. 这个实现还有哪些潜在坑？ #

• 悬空引用/野指针：当前代码中lambda捕获的是Foo对象的引用，一旦对象销毁，回调执行时会访问已释放的内存，导致崩溃、数据损坏等未定义行为，这是最直接的致命风险。
• 生命周期不匹配：异步场景下，Manager持有回调的时间很可能超过Foo对象的存活周期，这种情况几乎必然触发悬空引用问题。
• 多线程竞态：在多线程环境中，若Foo对象在一个线程被销毁，同时回调在另一个线程执行，即使添加了存活标记，也可能出现标记刚设置为false、对象内存就被回收，而回调尚未完成检查的情况，依然会导致非法访问。
• 调试困难：悬空引用导致的崩溃通常没有明确的错误提示，很难直接定位到是回调引用了已销毁的对象，排查难度较大。
• 捕获失误：若不小心捕获了局部变量的引用（如函数内临时创建的Foo对象），同样会导致悬空引用，异步场景下这类错误更容易出现且更难排查。

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