对象逃逸导致的竞态是指本应限于某线程或作用域的对象，其地址被暴露给其他线程使用，而原线程可能已销毁该对象，引发随机崩溃、use-after-free等未定义行为；典型场景包括构造函数中传递this指针、lambda捕获局部对象后在线程中访问、返回栈对象地址等。
对象逃逸引发的竞态无法靠肉眼静态检查定位，必须结合 ThreadSanitizer 检测 + 生命周期图谱分析才能确认。
什么是对象逃逸导致的竞态
对象逃逸（Object Escape）指一个本应在某线程或作用域内生存的对象，其地址被无意中暴露给其他线程使用，而此时原线程可能已销毁该对象。典型表现不是 crash on startup，而是随机崩溃、use-after-free、读到垃圾值或断言失败。
常见逃逸点包括：this 指针在构造函数中被传入 std::thread、lambda 捕获局部对象后在线程中访问、返回栈对象地址、成员函数指针绑定到未完成构造的对象。
- 构造函数里调用
std::thread([this]{ ... })—— 此时this所指对象尚未构造完毕，且主线程可能在子线程启动后立即退出作用域 - 将局部
Worker对象的引用/指针传给std::thread，但没保证主线程 wait 到线程真正结束才析构 - 成员函数通过
std::bind或 lambda 捕获this，但调用时机不可控（如异步回调），对象早已被析构
ThreadSanitizer 是唯一靠谱的第一排查手段
日志和 gdb 很难复现这类问题，因为逃逸本身不报错，出问题时早已过了“泄露点”。-fsanitize=thread 会在首次检测到跨线程访问已销毁内存时直接中断并打印堆栈：
立即学习“C++免费学习笔记（深入）”；
WARNING: ThreadSanitizer: heap-use-after-free
Read of size 8 at 0x7b0c00001230 by thread T2
#0 Worker::do_work worker.h:42
#1 <lambda> main.cpp:15
Previous write of size 8 at 0x7b0c00001230 by thread T1
#0 Worker::~Worker worker.h:28
#1 std::default_delete<Worker>::operator() unique_ptr.h:85
- 编译时务必加
-fsanitize=thread -g -O1（-O2+可能抑制部分报告） - 运行时需设置环境变量
TSAN_OPTIONS="halt_on_error=1"避免只警告不中断 - 不要依赖
std::cout日志定位——它本身会干扰逃逸路径，且输出乱序掩盖真实顺序
如何画出生命周期图谱辅助判断
一旦 TSan 报告可疑地址，下一步是手动画出对象创建、线程启动、析构三者的时序关系。重点标出：
- 哪个线程构造了对象（T1？T2？main？）
- 哪个线程持有该对象的裸指针/引用（尤其注意 lambda 捕获方式：[this] vs [&] vs [=]）
-
join()或detach()的位置是否在对象析构之前；若用了detach()，必须确保对象生命周期长于线程 - 是否存在
std::shared_ptr误用：比如用get()提取裸指针传给线程，却没延长智能指针生命周期
例如，下面代码必然逃逸：
void start_worker() {
Worker w; // 栈对象
std::thread t([&w]{ w.run(); }); // 捕获引用，但 w 即将析构
t.detach(); // 主线程不等，w 析构后 t 还在访问
}
修复方式不是加锁，而是改用 std::shared_ptr<worker></worker> 并在线程中持有一份： [p = std::make_shared<worker>()] { p->run(); }</worker>。
为什么 std::mutex 在这里救不了命
很多人第一反应是“加个锁保护访问”，但这是无效的——锁只能防止并发读写，不能阻止对已释放内存的访问。一旦对象析构，其所有成员（包括 std::mutex 成员）也一并销毁，后续 lock() 调用本身就是未定义行为。
-
std::mutex不提供生命周期担保，它只是同步原语 - 析构后调用
mutex.lock()可能触发 SIGSEGV 或静默损坏 - 真正要解决的是“谁拥有对象”和“谁决定何时销毁”，而非“怎么串行访问”
复杂点在于：逃逸往往藏在间接调用链里，比如通过回调注册、事件循环投递、第三方库接口传入。这种情况下，必须逐层确认每个接收方是否做了生命周期延长（如拷贝 shared_ptr），而不是假设“对方会自己管理”。
