主线程析构对象后detach线程仍用this必崩溃，属典型悬挂指针；应改用std::weak_ptr+enable_from_this做存活检查，或用shared_ptr严格管理跨线程对象生命周期。
主线程析构对象后，detach线程仍在用 this —— 这类崩溃几乎必现，不是概率问题。
detach 线程捕获 this 引用后对象已销毁
这是最典型的悬挂指针场景：子线程通过 [&] 捕获了外围对象的 this，但主线程在 startOpt() 返回后立刻析构该对象，而子线程还在循环调用 saySometing()。此时 this 指向的内存早已释放，访问成员函数或成员变量即触发段错误。
- 即使
saySometing()是空函数，调用它仍需通过虚表或 this 调度，this为野指针时行为未定义 -
std::thread::detach()后，子线程生命周期完全脱离主线程控制，无法靠作用域自动同步 - Clang Static Analyzer 和 AddressSanitizer 都能捕获这类 use-after-free，但必须在编译时启用
-fsanitize=address
std::weak_ptr + enable_from_this 是安全解法
不能靠“别用 [&]”这种回避策略 —— 很多业务逻辑必须访问对象状态。正确做法是让对象自己管理生存期，用 std::weak_ptr 在子线程中做存活检查。
- 类需继承
std::enable_from_this<t></t>，并在 lambda 中捕获weak_from_this()的拷贝 - 每次调用前用
lock()获取shared_ptr，返回nullptr说明对象已析构，应退出循环 - 注意：不能在构造函数里调用
shared_from_this()，此时shared_ptr尚未建立，会抛std::bad_weak_ptr
std::function 存储成员函数指针也会引发析构崩溃
如果把成员函数包装进 std::function<void></void> 并跨线程传递（比如放进队列、定时器），而对象在 std::function 被调用前已析构，后果和直接捕获 this 一样 —— std::function 析构时尝试清理内部存储的绑定对象，可能访问已释放内存。
- 成员函数指针本身不带对象实例，
std::bind(&A::saySometing, this)或[this](){ this->saySometing(); }才真正持有this - AddressSanitizer 对
std::function析构路径中的 UAF 有良好覆盖，但需确保编译时开启-fsanitize=address且未被 O2/O3 优化干扰 - 避免把
std::function存入全局容器或跨模块传递，尤其当其捕获了局部对象引用或this
libtorch 多线程推理中模型对象析构与线程竞争
libtorch 场景下，崩溃常发生在主线程卸载模型（析构 torch::jit::script::Module）后，工作线程仍在调用 forward()。这不是普通悬挂指针，而是框架内部张量引用计数、autograd 上下文、CUDA stream 等共享状态被破坏。
- 必须保证模型对象的生命周期严格长于所有使用它的线程 —— 最稳妥是主线程不析构，改用
std::shared_ptr管理，并在线程中持有weak_ptr - 每个工作线程内必须单独构造
c10::InferenceMode，不能在主线程构造一次就认为全局生效 - GPU 推理时，
torch::cuda::synchronize()或显式等待 stream 完成后再析构模型，否则 CUDA kernel 可能仍在执行
真正的难点不在“怎么写”，而在“谁负责生命周期”。一旦涉及 detach 线程、回调注册、异步任务队列，就必须明确对象所有权归属 —— 是由创建者管到底，还是交由线程自己 hold 住？含糊其辞的设计，迟早会在某个低概率时机崩给你看。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
