VSCode 无法自动中断内存泄漏，需结合 AddressSanitizer 定位错误行（如 foo.c:42），在 VSCode 中手动跳转设条件断点或内存访问断点，并通过堆快照、GC 日志与引用分析闭环排查。
VSCode 本身不直接提供“内存泄漏中断”功能——它无法在对象未被释放时自动暂停，因为那不是调试器能静态捕获的事件。真正可行的路径是：用运行时检测工具（如 Valgrind、AddressSanitizer 或 Java 的 GC 日志）定位可疑区域，再回到 VSCode 中对相关代码设置**条件断点 + 内存访问断点 + 对象生命周期观察点**，形成闭环排查。
AddressSanitizer 报错后怎么在 VSCode 里精准跳转到问题行
AddressSanitizer（ASan）会在检测到 use-after-free、heap-buffer-overflow 等问题时打印带栈帧的错误信息，例如：
==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000030 at pc 0x000000401234 bp 0x7fff12345678 sp 0x7fff12345660
READ of size 4 at 0x602000000030 thread T0
#0 0x401234 in process_data foo.c:42
这个 foo.c:42 就是关键线索。操作要点：
- 确保编译时启用了 ASan：
gcc -g -fsanitize=address -o a.out foo.c，且launch.json中的program指向该可执行文件 - 在
launch.json的配置中添加环境变量："env": { "ASAN_OPTIONS": "abort_on_error=1" }，让进程在报错时立即终止并保留栈信息 - VSCode 调试启动后，若 ASan 触发，调试器会停在崩溃指令处（通常不是源码行，而是汇编），此时不要依赖“自动跳转”，而是手动打开
foo.c，跳到第 42 行，右键设断点 - 更可靠的做法：在疑似释放/重用前的位置（如
free(ptr)后一行、或ptr->field访问前）设条件断点：ptr != nullptr && (uintptr_t)ptr == 0x602000000030，复现时就能提前拦截
Java 中如何用断点辅助发现内存泄漏（非自动中断）
Java 没有传统意义的“内存访问断点”，但可通过 GC 行为+对象引用链反推。VSCode（配合 Debugger for Java）能做的，是帮你卡在关键节点观察：
- 在对象创建处设**条件断点**，例如：
className.equals("LargeCacheEntry")，配合hitCount设为 1000，确认是否异常堆积 - 在
finalize()（已弃用）或Cleaner回调里设断点，观察回收时机是否严重滞后 - 在疑似持有引用的集合类（如
static Map<string object> cache</string>）的put/remove方法入口加**方法断点**，右键选择 “Suspend policy: Thread”，避免全局阻塞 - 调试中打开 “Variables” 面板，展开对象 → 右键 “View Heap Dump”（需安装 Extension Pack for Java），导出后用 Eclipse MAT 分析支配树
C/C++ 下用硬件内存断点监控 malloc/free 关键地址
这是最接近“内存泄漏中断”的硬核做法，适用于 Linux/macOS 上的 cppdbg + LLDB 或 Windows 上的 cppvsdbg：
- 先在调试会话中运行程序，停在初始化后（比如
main入口），用控制台执行：memory read -f x -s 8 -c 1 0x602000000030确认地址有效 - 设置写入断点：
watchpoint set write -w 8 -x 0x602000000030（LLDB）或hbreak *0x602000000030（GDB） - 注意：硬件断点数量有限（通常 4 个），优先用于监控已知泄露对象的首地址；软件 watchpoint（
watch命令）虽无数量限制但性能开销大，慎用于高频分配路径 - 若你怀疑某块内存被反复
free，可在free函数上设断点，条件为：addr == 0x602000000030，这样第二次 free 同一地址时就会中断
真正的内存泄漏排查从来不是靠“一个断点就中断”，而是靠“ASan/Valgrind 定位异常模式 → 源码级条件断点缩小嫌疑范围 → 内存视图或堆转储验证对象状态”。最容易被忽略的是：忘记在 launch.json 中启用符号调试（-g 编译）、或误以为 Java 的 Object.finalize() 还能被可靠触发。
