很多人会把 free 命令中的 shared 字段误认为是 Linux IPC 共享内存大小，其实这是一个非常常见的理解偏差。这个字段真正反映的，是 tmpfs 挂载点（例如 /dev/shm）所占用的内存情况，并不包含通过 ipcs -m 查看的 System V 共享内存段。那么，Linux 怎么查看共享内存大小才更准确？如果要查询 System V 共享内存，应使用 ipcs -m；如果要查看 POSIX 共享内存，可以执行 ls -l /dev/shm/；而若想进一步了解内核层面的共享内存实际消耗，则需要重点查看 /proc/meminfo 里的 Shmem 字段。
free 命令里 shared 字段不等于 IPC 共享内存
很多用户看到 free 输出中的 shared 列时，往往会直接理解成 System V 或 POSIX 共享内存占用，但这种理解并不准确。实际上，这个字段在较新的 Linux 内核（5.0+）中已经逐步被弃用，不少发行版（如 Ubuntu 22.04、CentOS 8+）默认不是显示为 0，就是干脆不再展示。即便它存在数值，表示的也不是 ipcs -m 管理的 IPC 共享内存，而是 tmpfs 挂载点（如 /dev/shm）已经使用的内存空间。
查 System V 共享内存用 ipcs -m
如果你想查看 Linux 中的 System V 共享内存大小，最直接、最常用的方法就是使用 ipcs -m，它专门用于列出当前系统中的所有 System V 共享内存段：
ipcs -m可显示所有共享内存段的 ID、所有者、权限、大小（bytes）、挂接数（nattch）等详细信息ipcs -mu只展示汇总结果，例如总段数、总字节数以及最大共享内存段大小- 如果只想筛选某个用户或某个进程创建的共享内存段，可结合
ipcs -m | grep进行过滤
需要注意的是：ipcs 无法显示 POSIX 共享内存，也就是通过 shm_open() 创建的那一类。这类共享内存通常位于 /dev/shm 目录下，本质上属于 tmpfs 文件系统的一部分。
查 POSIX 共享内存看 /dev/shm 目录
POSIX 共享内存本质上是通过 shm_open() 在 /dev/shm 中创建的文件，因此要查看这类共享内存大小，核心思路就是检查该目录下文件的占用情况。虽然表面看起来像“文件大小”，但实际对应的是内存映射资源：
ls -l /dev/shm/可查看所有 shm 文件及对应大小，单位通常为字节du -sh /dev/shm/* 2>/dev/null | sort -h可以按占用大小排序显示，同时忽略无权限访问的条目df -h /dev/shm可查看整个 tmpfs 分区的已用空间和可用空间（默认上限通常是 64MB，也可以通过 mount 参数调整）
⚠️ 这里有一个很容易忽略的问题：如果程序执行了 shm_unlink()，但并没有及时 munmap，那么文件虽然已经从目录中删除，内存却仍然处于占用状态。这种情况下，ls 看不到相关对象，但 df 的已用空间已经把它统计进去了。遇到这种情况，通常需要结合 lsof +D /dev/shm 来定位仍然持有句柄的进程。
查内核实际分配的共享内存总量（含 Slab 缓存）
如果你真正关心的是“Linux 系统为了共享内存机制究竟实际消耗了多少物理内存”，那就不能只看用户态能直接看到的那部分。因为内核还会把共享内存相关的元数据、页表开销，以及 Slab 分配器产生的部分额外消耗一起算进去。此时，更准确的参考来源是：
cat /proc/meminfo | grep -i "shmem|shm"，重点查看Shmem:字段，它代表 tmpfs 与 shm 相关的总内存占用cat /proc/meminfo | grep -i "slab"中的SReclaimable可能包含一部分共享内存相关缓存，但无法完全精准拆分- 要特别注意：
Shmem:包含的是所有 tmpfs 实例（例如/dev/shm、/run等）的总量，并不只是 IPC 共享内存
更复杂的一点在于：System V 共享内存段本身通常不会直接体现在 /proc/meminfo 的 Shmem 统计中，因为它走的是匿名页路径；而 POSIX 共享内存（/dev/shm）则会计入 Shmem。正因为两者底层实现机制不同，所以在做 Linux 共享内存监控、排查共享内存占用或分析内存使用时，最好将它们分别查看、分开判断。
