VSS是虚拟内存总量，不反映真实占用；RSS统计驻留物理内存但重复计算共享部分；PSS按进程数均摊共享内存，总和等于实际物理占用；USS是进程独占内存，退出即释放，用于泄漏定位。
看进程占了多少内存，不能只盯着一个数字——VSS、RSS、PSS、USS各自反映不同层面的内存使用情况，混用容易误判。真正要定位内存问题，得知道哪个指标对应什么场景。
VSS：只是“能用多大”，不是“用了多少”
VSS（Virtual Set Size）是进程整个虚拟地址空间大小，包括已分配但尚未实际使用的内存（比如 malloc 后还没写入的堆页）、代码段、共享库映射、mmap 区域等。它不区分是否驻留在物理内存中，甚至可能包含被换出到 swap 的页面。所以 VSS 数值往往远大于实际物理占用，对分析真实内存压力基本没用。
- 典型表现：一个 Java 进程 VSS 可达 4GB，但 RSS 只有 800MB
- 命令查看：
ps -eo pid,vsz,comm | grep java（VSZ 列即 VSS，单位 KB） - 关键点：VSS 高 ≠ 内存紧张；它无法反映系统真实负载
RSS：算出了“在内存里”，但重复计算了共享部分
RSS（Resident Set Size）表示进程当前驻留在物理 RAM 中的内存总量，比 VSS 更贴近实际。但它把所有共享内存（如 libc、JVM 共享库、动态链接的 so 文件）全部计入每个使用它的进程——哪怕这些共享页在物理内存中只存一份。
- 举例：两个 nginx worker 进程各加载了同一个 200MB 的共享库，RSS 会分别显示 +200MB，加起来多算了一次
- 命令查看：
top中 RES 列，或ps -eo pid,rss,comm - 适用场景：快速筛查“谁占物理内存最多”，但不适合做总量评估或跨进程对比
PSS：最接近“真实贡献”的统计方式
PSS（Proportional Set Size）修正了 RSS 的重复计算问题：对每个共享内存页，按使用它的进程数量均摊。如果有 N 个进程共用某块 300MB 的共享库，每个进程的 PSS 只计入 300/N MB。所有进程 PSS 相加，就等于系统当前真实的物理内存占用总量。
- 仍是上面两个 nginx 进程的例子：PSS 各为 100MB（私有）+ 100MB（共享均摊），总和 400MB = 实际物理占用
- 命令查看：
smem -k -p（需安装 smem），或解析/proc/[pid]/smaps中 Pss 行求和 - 核心价值：判断整机内存是否吃紧、分析多进程服务的整体开销、做容量规划
USS：杀掉这个进程，能立刻回收多少
USS（Unique Set Size）是进程完全独占的物理内存，不含任何共享成分。它代表该进程带来的“净增量”内存消耗。当进程退出时，USS 对应的内存会立即释放回系统，而 PSS 中的共享部分则由其他进程继续持有。
- 内存泄漏排查首选 USS：如果某个进程 USS 持续缓慢上涨，基本可确认存在泄漏
- 命令查看：
smem -k -p中 USS 列，或cat /proc/[pid]/smaps | awk '/Private_Clean|Private_Dirty/{sum += $2} END{print sum " kB"}' - 注意：USS 通常最小，但对资源成本评估和故障归因最关键
一句话总结：VSS 是画饼，RSS 是毛估，PSS 是分账后的真实账单，USS 是你关掉它就能拿回来的钱。
