std::thread构造后必须detach或join，否则析构时调用std::terminate导致崩溃；传参需注意std::ref和std::move；避免隐式捕获this引发悬空指针；共享数据须用原子操作或互斥锁保护。
std::thread 构造后必须 detach 或 join
创建 std::thread 对象后，如果既没调用 join() 也没调用 detach()，对象析构时会调用 std::terminate()，程序直接崩溃。这是新手最常踩的坑。
-
join()：主线程阻塞等待子线程结束，适合需要结果或同步完成的场景 -
detach()：子线程后台运行，与主线程脱离关系，但需确保线程内不访问已销毁的局部变量或栈内存 - 推荐优先用
join()，除非明确需要后台异步且生命周期可控
传参时注意值传递、引用传递和 move 语义
std::thread 构造函数会对参数做拷贝（即使原函数形参是引用），所以想传引用必须显式用 std::ref()；想转移资源所有权（如 std::unique_ptr）必须用 std::move()。
int x = 42;
std::string s = "hello";
<p>// 错误：f1 中的 ref_x 实际绑定到 x 的拷贝，不是原始 x
std::thread t1([](int& ref_x) { ref_x = 100; }, x);</p><p>// 正确：用 std::ref 传递引用
std::thread t2([](int& ref_x) { ref_x = 100; }, std::ref(x));</p><p>// 正确：转移 unique_ptr 所有权
std::unique_ptr<int> ptr = std::make_unique<int>(99);
std::thread t3([](std::unique_ptr<int> p) { /<em> 使用 p </em>/ }, std::move(ptr));</p>避免在 lambda 中隐式捕获 this 导致悬空指针
成员函数中启动线程并捕获 this（比如 [this]() { ... }），若线程还在运行而对象已被销毁，就会访问非法内存。尤其在类生命周期短于线程时风险极高。
- 检查对象生命周期是否覆盖线程全程
- 改用值捕获所需字段（
[val = this->data]）而非整个this - 必要时用
std::shared_ptr<this_type>管理对象生命周期，并在线程内持有弱引用或共享引用 - 调试时可加日志或断点确认对象析构时机是否早于线程退出
线程间共享数据必须加锁或用原子操作
多个线程读写同一变量（如全局 int counter）而未同步，会导致未定义行为——结果随机、崩溃、静默错误。不要依赖“好像没出问题”。
立即学习“C++免费学习笔记（深入）”；
- 简单计数器优先用
std::atomic_int，性能好且无需锁 - 复杂逻辑（如修改结构体多个字段）必须用
std::mutex+std::lock_guard - 避免死锁：始终按固定顺序获取多个锁；慎用
std::try_lock或std::unique_lock超时机制
std::atomic_int counter{0};
std::mutex mtx;
<p>// 推荐：原子操作
counter.fetch_add(1, std::memory_order_relaxed);</p><p>// 必须：临界区加锁
{
std::lock_guard<std::mutex> lock(mtx);
// 修改共享数据结构...
}</p>多线程真正难的不是启动几个 std::thread，而是厘清数据归属、生命周期边界和同步粒度。一个没被 join() 的线程、一次忘记 std::ref 的传参、一段没锁的共享写入，都可能让程序在高负载下才暴露问题。
