The*_*eer 5 process scheduling time
有一个很好的问答来解释“真实”、“用户”和“系统”之间的关系。
它解释了为什么“真实”会发生变化的原因，并将“用户”和“系统”定义为进程在处理器上实际运行的时间。
现在让我们完全忽略“真实”。我注意到多次运行同一个应用程序时，它给出了不同的“系统”和“用户”。
$time dummy_app
user 0m0.032s
sys 0m0.064s
$time dummy_app
user 0m0.020s
sys 0m0.084s
dummy_app 只是一个从 0 到 100000 计数的 for 循环。
同一个二进制文件的执行会在处理器上花费不同时间的原因是什么？换句话说，为什么同一个应用程序的“用户”和“系统”不总是相同的？
这里的关键问题是 CPU 工作方式导致的不确定性行为。现代超标量 CPU 可以一次执行多条指令或更改要执行的命令的顺序（乱序执行）。关于您的示例，缓存使用的优化也可能适用。RAM 比 CPU 本身慢几个数量级，这就是使用密集缓存的原因。二进制文件的第二次运行可能会在缓存中运行，从而消耗更少的 CPU 周期（CPU 等待从内存检索数据的周期）。
关于real、user和sys进程时间统计的差异
其中一件事与另一件事不同。Real是指实际经过的时间；User 和 Sys 指的是仅由进程使用的 CPU 时间。
实际时间是挂钟时间 - 从通话开始到结束的时间。这是所有经过的时间，包括其他进程使用的时间片和进程阻塞的时间（例如，如果它正在等待 I/O 完成）。
User是进程内用户模式代码（内核之外）所花费的 CPU 时间量。这只是执行进程时使用的实际 CPU 时间。其他进程和进程花费的阻塞时间不计入此数字。
Sys是进程内内核所花费的 CPU 时间量。这意味着执行内核中的系统调用所花费的 CPU 时间，而不是仍在用户空间中运行的库代码。与“用户”一样，这只是进程使用的 CPU 时间。请参阅下面的内核模式（也称为“管理程序”模式）和系统调用机制的简要描述。
User+Sys会告诉您进程实际使用了多少 CPU 时间。请注意，这是跨所有 CPU 的，因此如果进程有多个线程，则可能会超过 报告的挂钟时间Real。请注意，在输出中，这些数字包括所有子进程（及其后代）的时间User和Sys时间，以及它们可以被收集的时间，例如通过wait(2)或waitpid(2)，尽管底层系统调用分别返回进程及其子进程的统计信息。