00 前言
最近内存的价格疯涨，老板们的压力自然会传递到开发牛马身上。
把内存用明白也更加明显地成了每个开发的必修课。
01 内存去哪儿了：Linux的“魔术表演”
平时开发测试环境或生产环境免不了出现 Out of Memory (OOM) 报错，最简单直接的排查应该是从“free”开始了。
登录服务器或嵌入式环境，执行 free -h：
total used free shared buff/cache availableMem: 16G 14G 256M 1.2G 1.8G 512MSwap: 4G 3.5G 512M
表面看来情况危急：16G内存中14G被占用，空闲仅剩256M。但请等一下——Linux内存管理最反直觉的特性即将登场。
在Linux眼中，未被使用的内存就是浪费的内存。因此，它会用闲置内存做两件事：
缓存（Cache）：存储最近从磁盘读取的数据，下次需要时直接从内存提供，速度提升百倍
缓冲区（Buffers）：暂存准备写入磁盘的数据，优化磁盘I/O效率
这就是上面 buff/cache 那1.8G的真相——它们不是被应用程序占用的，而是系统为了提高性能主动占用的“灵活内存”。
真正的可用内存看 available 列：512M。虽然仍不宽裕，但远比256M乐观。当应用程序需要更多内存时，Linux会立即释放这些缓存，毫秒级响应。
02 内存分类学：认识你的每一字节内存
要真正管理内存，需要理解Linux如何划分内存疆域：
用户空间内存：应用程序直接使用的部分。这也是我们通常最关心的部分。
内核空间内存：操作系统自用的内存，包括：
- • Slab内存：内核对象缓存（如文件描述符、网络套接字）
文件页缓存：就是前面提到的Cache，加速文件访问的神器
匿名页：没有对应磁盘文件的内存页，如堆内存，这部分内存无法通过释放缓存回收
共享内存：多个进程共用的内存区域，如数据库的共享缓冲区
理解这些分类至关重要。当内存告急时，你需要知道是哪类内存在膨胀，才能对症下药。
03 排查实战：当内存告急时，高手这样操作
第一步：快速定位内存大户
# 按内存使用率排序进程ps aux --sort=-%mem | head -10# 更详细的视图top -o %MEM# 或者使用更现代的htop（需安装）htop
第二步：深入分析进程内存详情
# 查看某进程的详细内存映射pmap -x <PID># 查看/proc文件系统获取更详细信息cat /proc/<PID>/status | grep -E 'Vm|Rss'**避坑指南：** 排查内存飙升，盯着 **RSS** 看。如果 RSS 持续上涨不回落，那才是真正的代码逻辑有问题，# 使用smem工具（更直观显示PSS/USS）smem -p -s rss
第三步：检查内核内存使用
# 查看Slab内存使用情况slabtop -s c# 查看/proc/meminfo获取完整内存统计cat /proc/meminfo | grep -E 'SUnreclaim|Slab|KernelStack'# 检查是否有内核内存泄漏cat /proc/meminfo | grep -E 'MemFree|Cached|Slab'
第四步：分析文件缓存占用
# 查看哪些文件占用了最多缓存vmtouch -v /path/to/directory# 或者使用pcstat工具（需安装）pcstat /path/to/file# 清理缓存（谨慎操作！）echo 3 > /proc/sys/vm/drop_caches # 清理页缓存、目录项和inode
04 内存泄漏：沉默的成本杀手
内存泄漏如同屋顶的渗水，初期不易察觉，终将导致灾难。Linux提供了多种工具进行检测：
Valgrind：C/C++程序的内存调试神器
valgrind --leak-check=full ./your_program
tcmalloc/heaptrack：分析堆内存分配
LD_PRELOAD="/usr/lib/libtcmalloc.so" HEAPCHECK=normal ./your_program
内核内存泄漏检测：
# 开启kmemleakecho scan > /sys/kernel/debug/kmemleak# 稍后查看报告cat /sys/kernel/debug/kmemleak
05 优化之道：从被动应对到主动管理
调整内核参数
# 修改swappiness，减少交换倾向（默认60）echo 10 > /proc/sys/vm/swappiness# 调整缓存压力（默认100，值越大越倾向于回收缓存）echo 50 > /proc/sys/vm/vfs_cache_pressure# 调整透明大页设置（某些场景需要关闭）echo never > /sys/kernel/mm/transparent_hugepage/enabled
配置OOM Killer行为
# 调整OOM分数，避免重要进程被杀echo -1000 > /proc/<PID>/oom_score_adj# 查看当前OOM配置sysctl -a | grep oom
监控与告警策略
# 使用/proc/meminfo关键指标watch -n 5 "grep -E 'MemAvailable|SwapCached|PageTables' /proc/meminfo"# 编写监控脚本#!/bin/bashTHRESHOLD=90MEM_USAGE=$(free | awk '/Mem/ {print $3/$2 * 100.0}')if (( $(echo "$MEM_USAGE > $THRESHOLD" | bc -l) )); then echo "内存使用率超过阈值: $MEM_USAGE%" # 触发告警逻辑fi
06 容器环境特殊考量
在Docker/K8s环境中，内存管理更加复杂：
# 查看容器内存限制docker stats --no-stream# 检查cgroup内存配置cat /sys/fs/cgroup/memory/memory.limit_in_bytescat /sys/fs/cgroup/memory/memory.usage_in_bytes# K8s中的内存请求与限制apiVersion: v1kind: Podmetadata: name: memory-demospec: containers: - name: memory-demo-container image: polinux/stress resources: requests: memory: "100Mi" limits: memory: "200Mi" command: ["stress"] args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
容器环境常见问题：
- • 容器内
free 命令显示的是主机内存，而非容器限制
07 性能调优高级技巧
使用perf分析内存访问模式
# 记录内存访问模式perf record -e cache-misses -c 1000 ./your_program# 生成火焰图分析内存分配git clone https://github.com/brendangregg/FlameGraphperf record -F 99 -ag -- sleep 30perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > memory.svg
使用ebpf进行实时监控
# 使用bpftrace跟踪内存分配bpftrace -e 'kprobe:kmem_cache_alloc { @[comm] = count(); }'# 使用bcc工具集/usr/share/bcc/tools/memleak -p $(pidof your_program)
08 总结
作为开发要熟悉用好常用的内存管理工具。
同时重点关注RSS, 如果你的 RSS 曲线像珠穆朗玛峰一样只升不降，赶紧检查代码; 如果RSS 曲线平稳， 那问题应该不大， 无需过度焦虑。
