用 std::shared_ptr 替代裸指针可避免空指针崩溃，关键是要正确传递所有权：需将 shared_ptr 本身（而非 get() 原始指针）移入线程 lambda，配合 join() 或 jthread 管理生命周期，并用 TSan 检测释放后使用。
用 std::shared_ptr 替代裸指针管理生命周期
空指针崩溃常发生在主线程析构了对象，但子线程还在访问——裸指针不带所有权语义，编译器和运行时完全不管它是否有效。用 std::shared_ptr 是最直接的解法：只要还有线程持有该指针，对象就不会被销毁。
常见错误是只在主线程创建 std::shared_ptr，却把原始指针（.get()）传给线程函数：
auto obj = std::make_shared<MyClass>();
std::thread t([ptr = obj.get()] { ptr->do_something(); }); // ❌ 仍可能悬垂
正确做法是把 shared_ptr 本身移动进 lambda：
auto obj = std::make_shared<MyClass>();
std::thread t([ptr = std::move(obj)] { ptr->do_something(); }); // ✅ 持有所有权
- 注意 lambda 捕获方式：用
[ptr = std::move(obj)]，不是[&obj]或[obj]（后者会拷贝，但shared_ptr拷贝是安全的；std::move更明确） - 如果线程需长期持有，考虑用
std::weak_ptr避免循环引用，访问前调用lock()判断是否还有效 - 不要混用
shared_ptr和new/delete：对象必须由make_shared或shared_ptr构造，否则析构行为未定义
用 std::thread::join() 或 detach() 前确认对象存活范围
很多崩溃源于线程还没结束，主线程已退出作用域、析构局部对象。此时即使用了 shared_ptr，若其作用域结束（比如函数返回），引用计数归零，对象照样被删。
立即学习“C++免费学习笔记（深入）”；
典型场景：类成员启动线程，但线程函数捕获的是 this 或成员变量：
class Worker {
void start() {
thread_ = std::thread([this] { do_work(); }); // ❌ this 可能已被析构
}
std::thread thread_;
};
解决思路不是“加锁”，而是控制线程生命周期与对象生命周期对齐：
- 在析构函数中显式调用
thread_.join()（确保线程结束再析构） - 或改用
std::jthread（C++20），构造时自动关联停止源，析构时自动join() - 避免在线程函数中直接捕获
this；如必须，改用shared_from_this()（要求类继承std::enable_shared_from_this） - 若用
detach()，必须保证对象生存期长于线程——通常不推荐，极易出错
用 AddressSanitizer + ThreadSanitizer 定位悬垂访问
静态分析很难覆盖所有生命周期路径，运行时检测更可靠。Clang/GCC 都支持 TSan（ThreadSanitizer）专门抓数据竞争和释放后使用。
编译时加标志启用：
g++ -fsanitize=thread -fPIE -pie -g worker.cpp -o worker
TSan 会在程序访问已释放内存时立即报错，输出类似：
WARNING: ThreadSanitizer: heap-use-after-free Read of size 8 at 0x7b1c00000010 by thread T2
关键点：
- 必须开启
-g才能定位到具体行号 - TSan 会显著降低性能（约 2–5×），仅用于调试，不可上线
- 它能发现裸指针、
unique_ptr释放后访问，但对shared_ptr管理的对象无效（因为没真正释放） - 配合 ASan（AddressSanitizer）一起开效果更好：
-fsanitize=address,thread
避免在 lambda 中隐式捕获导致意外延长生命周期
看似安全的捕获可能埋雷。例如：
void launch(std::shared_ptr<Data> data) {
auto task = [data] { process(*data); }; // ✅ 显式捕获
std::thread t(task);
t.detach(); // ⚠️ data 生命周期绑定到 task，但 task 可能比 data 活得久
}
问题在于 detach() 后，lambda 对象及其捕获的 data 在堆上独立存活，而外部 data 变量早已销毁——但引用计数仍在，对象没被删，表面看没问题。可一旦其他地方提前 reset() 了该 shared_ptr，就立刻悬垂。
- 优先用
join()，避免detach() - 若必须
detach()，确保捕获的shared_ptr来自长期存活的源头（如全局对象、单例、或由std::jthread管理） - 警惕隐式捕获
[=]：它会把当前作用域所有自动变量都拷贝一份，包括你不关心的临时shared_ptr，容易误判生命周期 - 用
std::weak_ptr+lock()显式检查有效性，比依赖引用计数更主动
查这类问题最有效的组合是：写代码时默认用 shared_ptr + join()，调试阶段必开 TSan，遇到诡异崩溃先看 sanitizer 输出里有没有 heap-use-after-free ——90% 的“空指针”其实根本不是空指针，而是野指针。
