如何编写内存泄漏排查脚本

从入门到精通

目录导读

• 什么是内存泄漏？为什么需要排查脚本？
• 排查脚本的核心原理与工具选择
• 基础版：Python内存泄漏排查脚本编写
• 进阶版：Java/Node.js内存泄漏脚本实战
• 自动化监控脚本：集成报警与日志分析
• 常见问题与避坑指南
• FAQ：内存泄漏排查脚本高频问答

什么是内存泄漏？为什么需要排查脚本？

问：内存泄漏到底指什么？
答：内存泄漏（Memory Leak）是指程序在运行过程中动态分配的内存，在不再需要时未被正确释放，导致系统可用内存持续减少，长期运行的服务（如Web服务器、数据库、微服务）一旦出现泄漏，最终会导致OutOfMemoryError（OOM）或系统崩溃。

问：为什么手动排查不够，需要写脚本？
答：手动排查依赖top、jmap、gdb等工具，但存在三大痛点：

1. 难以持续跟踪：内存变化是时间维度的累积，手动记录效率低
2. 环境差异大：生产环境限制多，无法随意挂载调试工具
3. 泄漏特征模糊：非明显增长时，需要对比多个时间点的堆转储（heap dump）

编写排查脚本可以自动化捕获内存快照、分析增长模式、甚至触发GC（垃圾回收）后对比差异,极大提升定位效率。

排查脚本的核心原理与工具选择

核心原理

任何排查脚本都基于三个关键步骤：

1. 监控内存使用指标：获取进程的RSS（常驻内存）、堆使用量、GC频率等
2. 捕获堆转储：在内存异常时生成heap dump或核心转储
3. 对比分析增长：通过不同时间点的快照，找出“未被回收的对象集合”

工具选择清单

场景	推荐工具	脚本语言
Java应用	jmap, jcmd, VisualVM API	Python/Bash
Node.js	--inspect + Chrome DevTools	Node.js自身或Python
Python应用	tracemalloc, objgraph	Python
通用进程	/proc/[pid]/smaps, psutil	Python/Bash
分析堆转储	Eclipse MAT, JProfiler	脚本生成快照后由工具分析

提示：生产环境优先使用jcmd或kill -3生成线程/堆信息,避免附加代理导致性能下降。

基础版：Python内存泄漏排查脚本编写

下面是一个完整的Python脚本，监控指定Java进程的内存变化,并在超过阈值时自动生成堆转储：

#!/usr/bin/env python3
import subprocess
import time
import os
import sys
from datetime import datetime
# 配置区域
PID = os.getenv('TARGET_PID', 12345)  # 目标进程PID
MEMORY_THRESHOLD_MB = 1024            # 内存阈值，单位MB
DUMP_DIR = '/tmp/heap_dumps'
INTERVAL_SEC = 30                     # 采样间隔
MAX_DUMPS = 5                         # 最大快照数量
os.makedirs(DUMP_DIR, exist_ok=True)
def get_memory_mb(pid):
    """通过/proc获取进程RSS内存"""
    try:
        with open(f'/proc/{pid}/status') as f:
            for line in f:
                if line.startswith('VmRSS:'):
                    # 格式: "VmRSS:   123456 kB"
                    kb = int(line.split()[1])
                    return kb / 1024
    except Exception as e:
        print(f"[错误] 读取内存失败: {e}")
        return None
def generate_heap_dump(pid, reason):
    """使用jmap生成堆转储"""
    timestamp = datetime.now().strftime('%Y%m%d%H%M%S')
    dump_file = f'{DUMP_DIR}/heap_{timestamp}_{reason}.hprof'
    cmd = f'jmap -dump:live,format=b,file={dump_file} {pid}'
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    if result.returncode == 0:
        print(f"[快照] 已生成堆转储: {dump_file}")
        return dump_file
    else:
        print(f"[错误] 生成堆转储失败: {result.stderr}")
        return None
def monitor():
    memory_history = []
    dump_count = 0
    print(f"开始监控PID={PID}，内存阈值={MEMORY_THRESHOLD_MB}MB，采样间隔={INTERVAL_SEC}s")
    while dump_count < MAX_DUMPS:
        current_mb = get_memory_mb(PID)
        if current_mb is None:
            print("无法获取内存信息，退出监控")
            break
        timestamp = datetime.now().strftime('%H:%M:%S')
        print(f"[{timestamp}] 当前RSS: {current_mb:.1f}MB")
        memory_history.append((timestamp, current_mb))
        # 检查内存是否超过阈值且持续上升
        if current_mb > MEMORY_THRESHOLD_MB:
            # 与上一次记录对比
            if len(memory_history) >= 3:
                last_three = [m[1] for m in memory_history[-3:]]
                if all(last_three[i] <= last_three[i+1] for i in range(2)):
                    print("检测到内存持续上升，触发堆转储")
                    generate_heap_dump(PID, 'rising')
                    dump_count += 1
        time.sleep(INTERVAL_SEC)
    print("监控结束，生成内存趋势报告：")
    for t, m in memory_history:
        print(f"{t} -> {m:.1f}MB")
if __name__ == '__main__':
    try:
        monitor()
    except KeyboardInterrupt:
        print("\n用户中断监控")

脚本核心逻辑：

• 每30秒采集一次/proc/pid/status中的VmRSS
• 当内存连续三次上升且超过阈值时，触发jmap -dump:live生成堆转储（只保留存活对象，减少文件大小）
• 自动限制最大快照数量，避免磁盘爆满

实战扩展：如何检测Java中的类加载泄漏？

在上述脚本的基础上，可以增加jcmd命令来获取类的实例数量：

jcmd {PID} GC.class_stats

通过对比不同时间点的类实例数，发现不断增长的类（典型泄漏模式：HashMap、ArrayList、ThreadLocal等）。

进阶版：Java/Node.js内存泄漏脚本实战

场景：Java Spring Boot应用内存泄漏排查

编写一个更专业的Bash + Python混合脚本：

#!/bin/bash
# java_leak_check.sh
PID=$1
MAX_LOOPS=20
SLEEP=10
for i in $(seq 1 $MAX_LOOPS); do
    echo "=== 第${i}次采样 ==="
    # 1. 获取内存信息
    RSS=$(ps -p $PID -o rss= 2>/dev/null)
    echo "RSS: ${RSS}KB"
    # 2. 获取GC情况
    jstat -gc $PID 2>/dev/null | tail -1 | awk '{print "YGC次数:", $7, "YGC耗时:", $8, "FGC次数:", $11, "FGC耗时:", $12}'
    # 3. 获取老年代使用率
    jstat -gcutil $PID 2>/dev/null | tail -1 | awk '{print "老年代使用率:", $4"%"}'
    # 4. 如果RSS增长超过10%且FGC次数未增加，则可能是泄漏
    FIRST_RSS=${FIRST_RSS:-$RSS}
    GROWTH_RATE=$(echo "scale=2; ($RSS - $FIRST_RSS) / $FIRST_RSS * 100" | bc)
    if (( $(echo "$GROWTH_RATE > 10" | bc -l) )); then
        echo "内存增长${GROWTH_RATE}%，执行堆转储..."
        jmap -dump:live,format=b,file=/tmp/leak_$i.hprof $PID
    fi
    sleep $SLEEP
done

关键技巧：

• 使用jstat -gcutil观察老年代（Tenured/Old）使用率，如果持续上升但FGC（Full GC）次数很少，说明对象无法被回收，基本确认泄漏。
• 结合-XX:+HeapDumpOnOutOfMemoryError参数自动生成OOM时的快照,脚本则负责正常运行期间的趋势采集。

场景：Node.js内存泄漏排查脚本

Node.js的内存泄漏常表现为“垃圾回收后内存依然不降”，脚本思路：

// node_leak_check.js (需配合 --inspect 启动)
const inspector = require('inspector');
const fs = require('fs');
async function captureHeapSnapshot() {
    const session = new inspector.Session();
    session.connect();
    const result = await new Promise((resolve, reject) => {
        session.post('HeapProfiler.takeHeapSnapshot', { reportProgress: false }, (err, data) => {
            if (err) reject(err);
            else resolve(data);
        });
    });
    session.disconnect();
    const timestamp = Date.now();
    fs.writeFileSync(`/tmp/heap_${timestamp}.heapsnapshot`, JSON.stringify(result));
    console.log(`快照已保存: /tmp/heap_${timestamp}.heapsnapshot`);
}
// 每60秒检测一次RSS，如果持续增长则抓快照
const threshold = 200 * 1024 * 1024; // 200MB
let previousRSS = process.memoryUsage().rss;
setInterval(async () => {
    const currentRSS = process.memoryUsage().rss;
    const diff = currentRSS - previousRSS;
    console.log(`RSS: ${(currentRSS / 1024 / 1024).toFixed(2)}MB, 变化: ${(diff / 1024 / 1024).toFixed(2)}MB`);
    if (diff > threshold) {
        console.log('检测到内存明显增长，捕获堆快照...');
        await captureHeapSnapshot();
    }
    previousRSS = currentRSS;
}, 60000);

注意：Node.js的堆快照文件非常大（几百MB），需要确保磁盘空间,并限制定时清理旧快照。

自动化监控脚本：集成报警与日志分析

生产环境需要将排查脚本包装成服务或定时任务，并集成报警，推荐架构：

1. 采集层：使用Python脚本定期采集/proc/pid/status、jstat、pmap数据
2. 分析层：将数据写入InfluxDB或Prometheus，使用Grafana可视化
3. 触发层：当内存连续N次采样超过阈值，执行堆转储并调用Webhook（如Slack、钉钉）
4. 清理层：使用logrotate或定时删除超过7天的堆转储文件

示例：定时任务配置（crontab）

*/5 * * * * /opt/scripts/memory_check.py --pid 12345 --threshold 1500 >> /var/log/memory_leaks.log 2>&1

报警示例（Python）

def send_alert(message):
    import requests
    webhook_url = 'https://hooks.example.com/alerts'
    requests.post(webhook_url, json={'text': message})

常见问题与避坑指南

jmap触发应用暂停怎么办？

• 使用-dump:live选项会触发Full GC，导致应用暂停数秒，生产环境建议：
  • 错峰执行（凌晨低流量时段）
  • 使用jcmd代替jmap，或者使用-XX:+HeapDumpOnOutOfMemoryError自动参数

堆转储文件过大，磁盘被撑爆？

• 限制最大快照数量（如5个），并在脚本中检查磁盘剩余空间（df -h）
• 启用压缩：gzip -c /tmp/heap.hprof > /tmp/heap.hprof.gz

脚本无法监控Kubernetes容器内的进程？

• 使用shareProcessNamespace: true让容器共享宿主进程空间
• 或通过容器API获取资源使用：kubectl top pod --containers

内存泄漏脚本本身占用内存过高？

• Python脚本建议使用sys.setrecursionlimit控制递归深度
• 避免在内存采集循环中加载大型库（如matplotlib），数据仅保留最近100个点

FAQ：内存泄漏排查脚本高频问答

Q：排查脚本应该以什么频率运行？
A：开发环境可每5秒采样一次；生产环境建议每30-60秒一次,避免过多IO影响性能。

Q：如何判断是内存泄漏还是正常缓存增长？
A：观察GC行为：正常缓存会被GC回收，而泄漏对象长期存在于老年代，FGC后内存不降；另一种方法是手动触发GC后对比前后RSS变化（jcmd {PID} GC.run）。

Q：有没有一键式排查脚本推荐？
A：开源项目如heapdump-leak-detector（云厂商定制版）、MLeak（Java专用）提供了完整方案,但建议你掌握本文核心原理后定制自己的脚本。

Q：堆转储分析工具哪个最好用？
A：推荐Eclipse MAT（支持OQL查询）和JProfiler（界面友好），免费方案可使用jhat,但已较老。

Q：脚本发现内存泄漏后，如何定位到具体代码行？
A：在堆转储文件中，查找“Dominator Tree”（支配树）中最大的对象，通常能追溯到某个集合（如HashMap$Entry、ArrayList），结合OQL语句如SELECT * FROM java.util.HashMap$Entry快速过滤。

Q：微服务架构下，如何批量排查多个服务？
A：编写Ansible剧本或Kubernetes CronJob，遍历所有Pod的PID执行脚本，结果汇总到ElasticSearch中,设置告警阈值。

Q：编写排查脚本的最佳实践有哪些？
A：

• 脚本必须处理异常（如进程不存在、权限不足）
• 使用绝对路径引用工具（/usr/bin/jmap）
• 增加--dry-run模式测试逻辑
• 输出结构化日志（JSON格式），便于后期检索
• 每次运行记录PID和时间戳，避免重复分析

---

你已经掌握了从基础到进阶的内存泄漏排查脚本编写方法，关键在于持续监控、自动转储和对比分析，建议先在测试环境验证脚本，再部署到生产系统，并搭配Grafana等可视化工具让内存变化趋势一目了然，排查脚本的核心价值是在泄漏造成宕机前发现它。