在运行几个进程时，我注意到htop显示某些进程正在消耗 CPU，但S在“状态”列（列S）中却有标记……这意味着进程处于休眠或空闲状态，但我知道它们没有处于休眠状态。它们正在积极运行。此外，在VIRT内存消耗中，它显示48.6G。当然，它不可能是 48.6 GB。这是不是其中的某个错误htop？我看过该man页面，但是否有其他信息来源可以更详细地提供这些缩写和解释？
答案1
我注意到 htop 显示某些进程正在消耗 CPU，但在状态列（S 列）中标记为 S...这意味着进程正在休眠或空闲，但我知道它们没有休眠。它们正在积极运行
他们不可以全部同时运行——每个 CPU 核心只有一个任务可以真正“运行”，其余任务必须等待调度程序到达。（例如，在单核 CPU 上，htop 只能看到本身就像在跑步……）
但是我思考真正的问题是 htop 实际上无法获取整个系统状态的“即时”快照（至少在 Linux 上不行）。相反，它必须读取每个进程的状态一次一个– 这本身需要一些 CPU 时间，在此期间其他进程可能会重新安排，并且扫描实际上可能会错过正在运行的进程。
（例如，当 htop 读取 /proc/12345/status 时，它可能会显示“状态：S”，因为它处于休眠状态而进程 23456 正在运行......但是一旦 htop 到达 /proc/23456，它也可能会显示“状态：S”因为到那时，23456 已暂停，而 12345 是正在运行的进程，所以最终结果是两个进程都显示为休眠状态，即使两个进程都在“运行”。）
尽管 Linux 本身（即内核）也可能并不总是准确地报告“正在运行”的状态（由于各种原因，同样很可能与时间有关）。
另外，在 VIRT 内存消耗中，显示为 48.6G。当然不可能是 48.6 GB
可以，因为VIRT 不是内存消耗– 这是地址空间消耗，地址空间除了物理 RAM（或交换）外，还可以映射到许多其他东西。实际的“内存消耗”是该RSS列。
（举个例子，文件直接进入地址空间 - 映射整个 10GB 文件似乎会“消耗” VIRT 列中的 10GB，即使它几乎不消耗任何物理 RAM。再举一个例子，一些 Web 浏览器分配巨大的“保护”映射以将 JavaScript 与其余部分隔离开来；大多数映射保持为空，因此也不会消耗任何 RAM。）
但是，htop才不是您的屏幕截图实际上显示 48.8G。此列表中除一个“ffmpeg”项目外，其他所有项目都是线程（绿色），进程内的所有线程共享相同的内存 - 因此，无论有多少个线程，整个 ffmpeg 进程的 RSS 为 797M（虚拟地址空间为 1847M）。（按ShiftH隐藏线程。）
答案2
S方法可中断睡眠（等待事件完成）。CPU 消耗在一段时间内报告，并且“S”可能是该时间结束时的状态。进程可以一直在运行和休眠之间切换（例如休眠以等待硬盘读取字节）。
当某个程序的 CPU 消耗较高时，其他进程很难有机会在同一 CPU 核心上运行。在核心较少的计算机上，htop当高 CPU 消耗程序正在等待某些东西（磁盘、交换、网络、信号量等）时，最有可能获得其 CPU 时间。
值得注意的是，htop 的刷新率为 1 秒（默认情况下），因此当线程之间的时间分片以 10-100 毫秒为单位时，它必须做一些工作才能显示状态和时间。在最后一秒内，可能有 1/10/100 个线程获得了时间。
从所有这些得出的结论是，显示的htop只是计算机在前一秒发生的事情的摘要，而不是计算机在某个精确时刻的状态的精确列表或快照。