我对 GNU/Linux 中可用的进程信息有一些疑问进程文件系统。这最初是由于希望从应用程序中提取 vmPeak、vmSize、vmRSS 和 vmHWM。
我从一个工作假设开始，即
/proc/<pid>/status人类可读的版本/proc/<pid>/stat是机器可读的kernel.org 评论：
stat - 进程状态
status - 人类可读形式的进程状态
当我注意到时我意识到这不太正确虚拟峰值只能从 购买/proc/pid/status。
看起来/proc/pid/status实际上结合了多个地方的价值观并添加了一些自己的价值观。
鉴于我们/proc/pid/status是否有任何理由使用/proc/pid/stat？需要它什么？
为什么有两个 API？可能/proc/pid/stat会被弃用或者有用途吗？
stat不等价。它提供的字段较少。它只是稍微容易解析一点（使用如果你天真地这样做，就会发现微妙的错误）。任何使用 stat 的程序都可以轻松切换为使用 status。真正能打破的有几个？
我刚刚为两者编写了解析器（尽管最终我将其中一个用于 stat，因为 API 不太有用）。对于机器可读的内容来说，内容并不多。事实上，“状态”的解析器最终变得更加优雅，因为您可以将其直接读入您喜欢的任何类型的键值存储中。 Status 似乎更容易从任何语言解析并且可扩展。
有多少程序实际上依赖于“stat”而不是“status”？他们中的任何人真的需要这可能提供的微不足道的解析速度吗？
现在我明白，由于向后兼容性， stat 多年来无法删除，但您可以说“现在已弃用”，除非有充分的理由保留它（这将是我的问题的一个可能答案）。
如果性能是一个问题，那么通过虚拟文件系统将此内核信息转换为文本并返回的性能肯定低于库调用的性能。
不断添加新的 API 可能会令人讨厌这个答案建议，但鉴于其中很大一部分是稳定的，为什么没有 C 库 API，例如，系统信息？
答案1
内核仍然提供向后兼容性的原因/proc/…/stat是向后兼容，而不仅仅是与旧版本的程序兼容 - 如果您procps现在构建实用程序，您最终会得到以下程序（ps、pgrep、pidof等）仍在阅读/proc/…/stat。
一可以可以想象改为procps仅使用/proc/…/status；旧的性能参数不再相关，status从内核检索所需的时间与检索 所需的时间相同stat。但这对想要更新内核而不更改用户空间工具的现有系统没有帮助。
就内核而言，这是保留stat.为什么 Linux 内核有一个永不破坏用户空间的策略？
您当然可以自由选择仅使用/proc/…/status和/proc/…/stat完全避免。我不知道有任何普遍共识认为后者应该被视为已弃用；我从未见过它被讨论过（这并不意味着它没有被讨论过），并且它没有被标记为已弃用手册procfs页或在内核过时的 ABI 符号（其中包括/proc条目）。也许这只是惯性，如果您在更多内核开发人员可能会注意到的圈子中提出它，那么很明显，存在是共识。
（请注意，据我所知，中的某些字段stat在 中不可用— 至少是进程组和会话 ID。）status
关于sysinfo风格的界面，您总是可以提出一个建议。基于文本的界面不会消失，不仅是为了保持向后兼容性；以 Unix 风格系统中的许多文本处理工具可以使用的格式保存这些信息太方便了，无法摆脱。
答案2
https://lkml.org/lkml/2012/12/23/75
WE DO NOT BREAK USERSPACE!
只要依赖stat它的旧实用程序/应用程序不会被删除，它很可能永远不会被删除。
如果您想使用其中任何一个 - 这是您的选择。