17370845950

C++多线程使用_C++标准库多线程组件应用教程
标准库多线程组件需谨慎使用:std::thread析构前

必须join或detach,否则terminate;std::mutex须用lock_guard等RAII封装保证异常安全;std::atomic不保证复合操作原子性;std::async默认可能延迟执行,需显式指定launch::async确保并发。

标准库的 std::threadstd::mutexstd::atomicstd::async 足够应对绝大多数多线程场景,但直接裸用容易出错——尤其是资源释放顺序、异常安全和竞态边界没理清时。

std::thread 构造后必须显式管理生命周期

构造 std::thread 对象后,它就拥有了一个关联的执行线程。如果该对象在析构前既未调用 join() 也未调用 detach(),程序会直接调用 std::terminate() 终止,且不抛异常、不打印堆栈。

常见错误写法:

void worker() { /* ... */ }
void bad_example() {
    std::thread t{worker};  // 构造成功
    // 忘记 join/detach → 析构时 terminate!
}

正确做法:

  • 明确线程归属:需要等待结果 → 用 join();后台长期运行 → 用 detach()(但要确保所捕获变量的生命周期足够长)
  • 推荐封装:用 RAII 类(如自定义 scoped_thread)强制绑定 join()detach()
  • 避免临时对象绑定:不要写 std::thread{worker}().join(); —— 临时对象在语句末就析构,join() 调用无效

std::mutex 不能复制,且 lock/unlock 必须成对

std::mutex 是非可复制、非可移动类型,只能通过引用或指针共享。手动调用 lock()unlock() 极易遗漏(尤其在有异常分支的函数中)。

典型问题:

  • 忘记 unlock() 导致死锁
  • 异常路径跳过 unlock(),后续线程永远阻塞
  • 跨作用域重复 lock()(同一线程对同一 mutex 多次加锁 → 未定义行为)

务必使用 RAII 封装:

std::mutex mtx;
void safe_access() {
    std::lock_guard lk{mtx};  // 构造即 lock,析构即 unlock
    // 即使这里 throw 异常,lk 析构仍会 unlock
    do_something();
}

注意:std::lock_guard 不支持递归加锁;如需同一线程多次进入临界区,改用 std::recursive_mutex + std::lock_guard

共享变量读写必须同步,atomic 不等于万能

即使只读或只写单个内置类型(如 int),只要多个线程访问同一对象,且至少一个为写操作,就必须同步。编译器重排、CPU 乱序、缓存不一致都可能导致未定义行为。

std::atomic 可解决简单标量的无锁读写,但要注意:

  • 默认内存序是 std::memory_order_seq_cst,性能开销略高;高频场景可降级(如用 relaxed 做计数器,acquire/release 做同步点)
  • std::atomic 不保护复合操作:比如 counter++ 是读-改-写三步,必须用 fetch_add() 等原子操作,而非普通赋值
  • 结构体/类不能直接 atomic 化,除非是 trivially copyable 且满足对齐等限制;否则仍需 mutex 保护

std::async 默认可能不启动新线程

std::async 的启动策略由 std::launch 参数控制,默认是 std::launch::deferred | std::launch::async,意味着实现可选择延迟执行(类似惰性求值),直到你调用 get()wait() 才真正运行 —— 这不是 bug,是标准允许的行为。

后果:

  • 你以为并发执行,实际是串行延迟执行
  • 若只创建 std::future 但不调用 get()/wait(),延迟任务永远不会跑

确保并发执行的方法:

auto f = std::async(std::launch::async, []{ return heavy_work(); });  // 显式指定 async
// 此时线程立即启动,不依赖 get() 触发

另外注意:std::future 析构时若未取值,会阻塞等待完成 —— 这容易导致意外的主线程挂起,尤其在容器里存了一堆 future 却忘了遍历 get()

多线程最难的从来不是“怎么启动线程”,而是“哪些数据被谁在什么时刻访问”。标准库组件只是工具,真正决定正确性的,是你对共享状态边界的判断精度,以及对每处 lockatomicjoin 背后隐含约束的清醒认知。