C++自定义ThreadLoop多线程类偶发段错误、互斥锁断言失败排查

你的代码存在三处致命的生命周期与并发逻辑错误，共同触发未定义行为，最终表现为互斥锁断言失败、段错误、成员值异常。

具体错误说明 #

• 悬空引用捕获栈上临时函数对象
  Start方法中构造线程的lambda使用[&]默认引用捕获，其中引用的function是Start的形参，属于函数栈上的局部变量。Start在启动线程后会立刻返回，栈上的function随即被销毁，线程循环执行function()时访问的是已经失效的悬空引用，直接触发未定义行为。
• Stop()方法未等待线程真正退出，存在对象生命周期竞态
  你当前的Stop实现仅将mRunning设为false后硬休眠100ms就返回，既没有调用mThread.join()等待线程执行完循环逻辑退出，也没有任何校验机制确认线程已经停止。靠固定时长休眠等待线程退出是多线程编程的典型反模式：一旦系统调度负载较高、线程休眠超时导致100ms内未退出，Stop返回后如果ThreadLoop所属对象（比如Worker1实例）被销毁，仍在运行的线程会访问已经释放的mRunning、mMutex、mName等成员内存——这就是你调试时看到mName为空、互斥锁加锁触发mutex->__data.__owner == 0断言的直接原因：对象内存已经被释放或覆写。
  另外你在析构函数中调用Stop()也存在同样问题，析构执行完成后对象成员已经被销毁，如果线程还未退出，必然访问野内存。
• mRunning的检查存在数据竞争
  你在进入std::scoped_lock加锁前就直接读取mRunning判断线程是否运行，这个读操作和Stop()中对mRunning的写操作没有同步保护，属于C++标准定义的数据竞争，会导致判断逻辑随机失效，甚至出现重复启动线程的异常。

修复方案 #

1. 线程lambda改为值捕获任务函数，避免引用栈上的局部变量
2. Stop()方法中在设置mRunning为false后，必须调用join()等待线程完全退出，不能靠固定休眠等待
3. 对mRunning的所有读写都做好同步，避免数据竞争
4. 保证ThreadLoop对象销毁前，关联的线程已经完全退出

修复后的ThreadLoop参考实现：

class ThreadLoop
{
public:
  ThreadLoop(const std::string& name) : mName(name) {}
  ~ThreadLoop() { Stop(); }

  template <typename F>
  void Start(F&& function)
  {
    std::scoped_lock lock(mMutex);
    if (mRunning)
      return;
    if (mThread.joinable())
      mThread.join();

    mRunning = true;
    // 值捕获函数对象，避免悬空引用
    mThread = std::thread([this, f = std::forward<F>(function)]() {
      while (true)
      {
        std::scoped_lock lk(mMutex);
        if (!mRunning)
          break;
        f();
      }
      std::this_thread::sleep_for(std::chrono::milliseconds(10));
    });
  }

  void Stop()
  {
    std::unique_lock lock(mMutex);
    if (!mRunning)
      return;
    mRunning = false;
    // 先释放锁再join，避免和线程内加锁逻辑死锁
    if (mThread.joinable())
    {
      lock.unlock();
      mThread.join();
    }
  }

private:
  bool mRunning = false;
  std::mutex mMutex;
  std::thread mThread;
  std::string mName;
};

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