Linux如何查看特定程序的内存泄露情况 Valgrind使用入门-LINUX-PHP中文网

valgrind 不能直接检查正在运行的程序，必须在启动时介入；它通过动态插桩跟踪内存操作，不支持 attach 到已运行进程，正确做法是用 valgrind 包裹重新启动目标程序。

linux如何查看特定程序的内存泄露情况 valgrind使用入门

Valgrind 能不能直接查正在运行的程序

不能。Valgrind 必须在目标程序启动时就介入，它通过动态插桩（instrumentation）重写二进制指令来跟踪内存操作，因此无法 attach 到已运行的进程。如果你看到 valgrind --pid=1234 这类写法，那是无效的——valgrind 命令根本不支持 --pid 参数。

正确做法是：停止当前程序，改用 valgrind 包裹启动。例如原命令是 ./myapp --config=config.yml，排查时应运行：

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./myapp --config=config.yml

--leak-check=full：启用完整泄露检测（默认是 summary）
--show-leak-kinds=all：显示 definitely lost、indirectly lost、possibly lost、still reachable 四类结果
--track-origins=yes：定位未初始化内存的来源（对 Conditional jump or move depends on uninitialised value 类错误很关键）
避免加 --tool=memcheck：这是默认工具，显式指定不必要，还可能因拼写错误导致失败

为什么 valgrind 报 “Invalid read/write” 却没崩

因为 Valgrind 的 Memcheck 工具在用户态拦截所有内存访问，比操作系统更早发现越界行为。程序没崩溃，只是还没踩到保护页或触发 SIGSEGV——但行为已是未定义（UB），后续可能随机 crash、数据错乱或静默污染。

常见诱因包括：

使用了 malloc 分配但未 free 的指针，之后又继续读写（尤其多线程中释放后未置 NULL）
数组下标越界，比如 buf[1024] 定义却访问 buf[1024]（合法索引是 0–1023）
C++ 中 std::vector::data() 返回裸指针，但 vector 被 move 或 resize 后原指针失效
结构体内存对齐 padding 导致 memcpy 覆盖相邻字段

这类问题在 valgrind 下会明确报出 Invalid write of size X 并附调用栈，比 core dump 更早暴露隐患。

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

Valgrind 检测 C++ 智能指针泄漏是否可靠

基本可靠，但有前提：必须用标准库实现（libstdc++ / libc++），且编译时未定义 _GLIBCXX_DEBUG 等调试宏干扰内部结构。

Valgrind 不解析 C++ 语义，它只跟踪 malloc/new 和 free/delete 的底层调用。只要智能指针析构时正确调用了 delete（如 std::unique_ptr、std::shared_ptr 的默认 deleter），就不会被记为 leak。

若自定义 deleter 里漏掉 delete，valgrind 仍会报 definitely lost
std::shared_ptr 循环引用不会被 valgrind 标记为 leak（因为内存仍被引用），但会导致对象永不析构——需配合其他手段（如添加 weak_ptr 断点或用 AddressSanitizer + UBSan）交叉验证
避免用 std::make_shared 创建对象后，又用裸指针 new 手动管理同一块内存，否则 valgrind 会误判

性能太慢、跑不动怎么办

Valgrind 的 Memcheck 工具会让程序变慢 20–50 倍，内存占用翻倍，对 I/O 密集或实时性要求高的程序几乎不可行。

可切换更轻量的替代方案：

先试 addr2line -e ./myapp 0x401234 解析 core 文件地址，快速定位崩溃点
用 gcc -fsanitize=address,undefined 编译（ASan+UBSan），运行时开销仅 2–3 倍，能捕获多数内存错误，但不提供 leak summary
对长期运行服务，可结合 /proc/PID/status 中的 VmRSS 和 cat /proc/PID/maps | grep heap | wc -l 观察堆段增长趋势，再辅以 pstack 抓堆栈判断是否卡在某次分配
若必须用 valgrind，加 --run-libc-freeres=no（跳过 glibc 自清理）和 --freelist-vol=10000000（增大空闲块缓存）可小幅提速