ESP32-S2上FreeRTOS多线程类实现崩溃问题求助

核心问题：线程启动时机过早 + 无线程资源清理 #

你的程序崩溃的根本原因有两个，其中Thread类缺少析构函数是关键隐患之一，另一个更直接的问题是线程在子类对象未完全构造时就开始运行：

1. 线程过早启动导致未初始化成员访问 #

C++中派生类的构造顺序是：先调用基类构造函数，再初始化派生类成员，最后执行派生类构造函数体。你的Thread构造函数里直接调用xTaskCreatePinnedToCore启动线程，此时Object的m_Attr还没完成初始化，线程却已经进入run()循环访问m_Attr，这属于访问未初始化内存，行为完全未定义。单实例时可能因为调度巧合没触发崩溃，多实例时资源竞争或内存布局问题直接触发崩溃。

2. 缺少析构函数导致线程资源泄漏与悬垂指针 #

当Thread对象被销毁时（比如Builder实例被delete），默认析构函数不会对m_TaskHandle对应的线程做任何处理：

• 线程会继续运行，此时run()里访问的对象成员已经被释放，会触发悬垂指针访问，直接导致崩溃；
• 线程的任务句柄没有被清理，会造成FreeRTOS的资源泄漏。

所以必须为Thread类添加析构函数，同时还要调整线程启动时机，避免在构造函数中直接启动线程。

修复后的代码示例 #

调整Thread类：添加析构函数+延迟启动线程 #

class Thread {
  public:
    Thread(const char * p_Name="", int p_Priority=1, int p_Core=0)
      : m_Name(p_Name), m_Priority(p_Priority), m_Core(p_Core), m_TaskHandle(nullptr)
    {
      // 不在构造函数启动线程，改为手动调用start()
    }

    // 析构函数：停止线程并释放资源
    ~Thread() {
      if (m_TaskHandle != nullptr) {
        // 强制终止线程（若需要优雅退出，可添加循环控制变量）
        vTaskDelete(m_TaskHandle);
        m_TaskHandle = nullptr;
      }
    }

    // 手动启动线程，确保子类已完全构造
    void start() {
      if (m_TaskHandle == nullptr) {
        xTaskCreatePinnedToCore(Task, m_Name, 4096, this, m_Priority, &m_TaskHandle, m_Core);
      }
    }

    virtual void run() = 0;

  protected:
    static void Task(void* p_pPtr) {
      Thread* p_pThis = static_cast<Thread*>(p_pPtr);
      p_pThis->run();
      // 线程退出时自动删除自身任务句柄
      vTaskDelete(nullptr);
    }

    const char* m_Name;
    int m_Priority;
    int m_Core;
    TaskHandle_t m_TaskHandle;
};

调整Builder类：在子类构造完成后启动线程 #

class Builder {
  public:
    Builder() :
      m_Object_A(15, "A"),
      m_Object_B(20, "B")
    {
      // 子类构造完成后再启动线程，保证成员已初始化
      m_Object_A.start();
      m_Object_B.start();
    }

  private:
    Object m_Object_A;
    Object m_Object_B;
};

关键说明 #

• 析构函数的作用：确保对象销毁时，对应的线程被正确终止并释放FreeRTOS的任务资源，避免悬垂指针访问和资源泄漏；
• 延迟启动线程：必须等待派生类完全构造完成后再启动线程，保证run()中访问的所有成员都已初始化；
• 如果需要线程优雅退出，可以在Thread类中添加原子布尔变量（如std::atomic<bool> m_Running），在run()的循环中判断该变量，析构时设置变量为false，让线程自行退出后再删除句柄。

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