不能直接靠断点统计写次数，因断点仅暂停执行、不自动计数，多线程下无法区分来源；数据断点受限于x86 debug模式；跟踪点需手动包裹写操作；asan/tsan可检测竞争但不计数；精确统计须关优化、用instrumentation或etw。
为什么不能直接靠断点统计写次数
断点本身不记录触发次数，只暂停执行；F5继续后，你得手动数——10个线程并发改同一个 std::atomic_int，断点命中几十次，根本分不清谁改的、改了几次。更麻烦的是，std::mutex 加锁区域里设普通断点，会干扰线程调度，甚至掩盖竞态问题。
用数据断点（Memory Breakpoint）盯住对象内存地址
这是最接近“监控写次数”的原生手段，但有硬限制：只支持 x86 Debug 模式，x64 下 VS 不支持硬件数据断点。操作前先确认：
- 项目配置必须是
Win32（不是x64），且为Debug模式 - 目标对象不能在栈上频繁重建（比如循环里的局部变量），否则地址每次不同
- 必须先运行到对象已分配、地址稳定的时刻，再在“调试”→“窗口”→“内存”→“内存1”中右键“转到内存地址”，输入
&obj查看起始地址 - 右键该地址 → “断点” → “插入数据断点”，填入对象大小（如
sizeof(int)），勾选“写入”
命中时，调用堆栈能告诉你哪个线程、哪行代码写的，但不会自动计数——你需要手动在“断点”窗口里看“命中次数”列，或配合条件断点做累加。
用跟踪点（Tracepoint）+ 全局计数器打补丁
当数据断点不可用（比如 x64 项目），就退而求其次：把“写操作”显式包裹进一个可监控的函数入口，再用跟踪点埋点。例如：
std::atomic_int g_write_count{0};
void safe_write(int& target, int value) {
target = value;
++g_write_count; // 这一行设跟踪点
}
在 ++g_write_count 行设跟踪点，输出 {g_write_count}, thread: {$TID}，就能在“输出”窗口看到每次写入的序号和线程 ID。注意：
- 别在多线程高频路径里加这种日志，
std::atomic_int自增本身也有开销 - 如果原始写操作分散在多处（比如直接
a = 1、b += 2），就得全局搜索替换，成本高但可控 - 跟踪点不中断执行，适合观察频率，但看不到写前/写后的值变化
真正可靠的方案：用 AddressSanitizer 或 ThreadSanitizer
VS 自带的 AddressSanitizer（ASan）在 Debug x64 下可启用，它能报告对同一内存地址的并发写，但不统计次数；ThreadSanitizer（TSan）目前仅限 Clang/LLVM 工具链，VS 原生不支持。所以现实中最稳的做法是：
- 先用 TSan 编译验证是否存在竞争（导出为 LLVM IR 后用 clang++ -fsanitize=thread 测试）
- 确认逻辑安全后，用 RAII 封装写操作，例如
WriteTracer w("counter", &counter)，构造时记录线程 ID 和时间戳，析构时写入日志文件 - 避免依赖 IDE 界面功能——多线程写监控本质是 instrumentation 问题，不是调试界面问题
最后提醒：所有基于断点/跟踪点的计数都可能漏掉优化掉的写（如 Release 模式下编译器合并赋值），真要精确统计，必须关优化、用 instrumentation 编译，或者改用 ETW 事件追踪。这点容易被忽略，但决定结果是否可信。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
