不能只靠断点看对象析构，因std::shared_ptr持有或跨线程传递时，~MyClass()调用时机≠真正销毁时刻；析构可能延迟至任意线程中引用计数归零时，且异常可能跳过清理路径。
为什么不能只靠断点看对象析构
在多线程 C++ 程序中，~MyClass() 被调用的位置和时机不等于对象真正被销毁的时刻——尤其当对象被 std::shared_ptr 持有、或跨线程传递时，析构可能延迟到引用计数归零的任意线程上下文中。单纯在析构函数设断点，容易漏掉跨线程释放、或因异常跳过清理路径的情况。
用数据断点（Data Breakpoint）捕获对象内存释放
VS 调试器支持对对象首地址设置数据断点，比函数断点更可靠：
- 运行程序，在对象构造完成后（比如
new MyClass()返回后），在“调试”→“窗口”→“内存”中查看该对象指针值（如0x000002A1F8C4D000） - 打开“调试”→“新建断点”→“数据断点”，填入地址 + 对象大小（如
0x000002A1F8C4D000，长度sizeof(MyClass)） - 勾选“写入”触发条件（对象内存被覆写/回收时会触发）
- 注意：仅对堆上对象有效；栈对象生命周期短且不可靠，不建议设数据断点
结合 PDB 符号与内存快照定位悬空引用
若对象已被释放但仍有线程尝试访问，Access violation 错误往往发生在非析构位置。此时需确认：
- 确保编译时启用了
/Zi并生成了匹配的.pdb文件（否则内存快照无法解析类型） - 在疑似问题前拍一次内存快照（“诊断工具”→“内存使用率”→“拍摄快照”）
- 出错后立即再拍一次，对比两次快照中
MyClass实例数量变化，并检查“对象分配调用堆栈”是否指向某线程中未释放的std::shared_ptr - 若发现某次快照中对象已消失，但另一线程仍在访问其地址，说明存在悬空指针——重点检查该线程是否持有未同步的裸指针或弱引用失效后未判空
避免误判：线程局部存储（TLS）对象的特殊性
用 thread_local static MyClass instance; 声明的对象，其生命周期绑定于线程退出而非作用域结束。VS 调试器不会在主线程断点处显示其析构，也不会在“调用堆栈”里反映——它实际由 CRT 在线程终止时统一调用 _tls_callback 清理。若需监控，必须在目标线程内设断点，或改用 __declspec(thread) + 自定义 TLS 回调注册（通过 DllMain 或 FlsAlloc）。
立即学习“C++免费学习笔记（深入）”；
