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