排查内存溢出需建立“观察—定位—验证—固化”闭环：先看available和swap判断真溢出，再用ps/watch/proc定位rss持续增长进程，接着按java/c/c++/python选工具深挖泄漏源，最后通过脚本、jvm参数或cgroups固化监控。
排查进程频繁发生内存溢出，关键不是等它崩溃后再翻日志，而是建立“观察—定位—验证—固化”的闭环。重点在于区分是单次突发耗尽（如大文件加载），还是持续增长型泄漏（如对象不断new不释放）。下面分四步说清楚怎么做。
看整体趋势：确认是不是真溢出，而不是缓存占位
别只盯着 used 高就喊OOM——Linux把空闲内存优先当缓存用，这很健康。真正危险的信号是：
- available 持续低于总内存10%（比如32G机器只剩2G可用）
-
swap 使用量持续上涨，且
vmstat 1中 si/so 值稳定大于0 - dmesg -T | grep -i "killed process" 能反复查到同个进程被OOM Killer干掉
锁可疑进程：找出谁在悄悄吃内存
用组合命令快速筛出“内存占用稳居高位+还在涨”的进程：
-
ps aux --sort=-%mem | head -5—— 先看内存占比最高的几个 -
watch -n 3 'ps -p PID -o pid,%mem,rss,vsz,etime --no-headers'—— 观察指定PID的RSS（实际物理内存）和运行时长是否同步增长 -
cat /proc/PID/status | grep -E "VmRSS|VmSize|Threads"—— 查看RSS是否持续上升、线程数是否异常增多
特别注意：如果 VIRT 远大于 RSS（比如VIRT=5G，RSS=100M），大概率是虚拟地址空间分配多但没真用，未必是泄漏；而 RSS持续爬升+Private_Dirty同步涨，基本就是泄漏铁证。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
深挖内存行为：按语言类型选工具验证
不同语言的泄漏特征和工具差异很大，不能一概而论：
-
Java进程：用
jstat -gc PID 2000 5看Full GC频率是否飙升；再用jmap -histo PID | head -20查TOP类实例数，若java.lang.String或自定义对象数量随时间猛增，十有八九是HashMap未清理或静态集合撑爆 -
C/C++进程：开发阶段用
valgrind --leak-check=full ./binary；线上可临时启用malloc_info或通过/proc/PID/smaps查 Private_Dirty 字段变化 -
Python进程：启动时加
-m tracemalloc，或运行中用tracemalloc.start()+snapshot.compare_to()定位新增分配源头
固化监控：避免下次再被动救火
光靠手动查不够，得让系统自己盯住关键进程：
- 写个简单脚本每30秒记录一次目标进程的RSS和etime，存入日志，用
awk算增长率 - 对Java服务，在JVM启动参数里加上
-XX:+PrintGCDetails -Xloggc:gc.log，配合gcviewer看GC曲线是否越来越陡 - 用
cgroups v2给高风险进程划内存上限，比如echo "512M" > /sys/fs/cgroup/myapp/memory.max，超限直接OOM而非拖垮整机
不复杂但容易忽略
