Python – time.sleep(n) 是否占用大量 CPU？[重复]

问题描述：

我一直在考虑使用time.sleep(n)Python 脚本来让它以不同的间隔执行作业。伪代码如下所示：

total_jobs = [...]

next_jobs_to_run = next_closest(total_jobs)
min_time_to_wait = closestTime(nextJobsToRun)

wait until min_time_to_wait
run them all 
get next jobs

总而言之，程序会一直休眠，直到需要执行下一个作业。它运行作业，找到下一个要运行的作业，然后一直休眠，直到需要运行下一个作业（一直持续到无穷大）。我计划在 Linux 机器上运行它 - 使用 cron 作业是可能的。有人对此有什么看法吗？

解决方案 1：

不，它不占用大量 CPU 资源。

文档说：

暂停执行给定的秒数。

Python 实际上无法保证在所有可能的实现中，这意味着操作系统永远不会在休眠期间调度您的进程。但在每个平台上，Python 都会尝试做一些适当的事情来阻塞指定的时间而不使用任何 CPU。在某些平台上，这可能仍然意味着需要一点 CPU，但它会尽可能少。

特别是，由于您询问有关 Linux 以及可能有关 CPython 的问题：

在 Linux 和大多数其他 POSIX 平台上，通常使用select。请参阅3.3 源代码。

手册页说得很清楚，select暂停直到信号、超时或 I/O 就绪（在这种情况下，没有 fds，因此后者是不可能的）。

您可以阅读内核源代码以了解完整的细节，但基本上，除非出现任何意外信号，否则您根本不会被安排，除非在开始时可能会有少量的旋转select（作为对select几乎可以立即返回的情况的优化）。

在您的总结中，问题从“是否sleep占用大量 CPU”变为“我应该使用sleep，还是使用 cron 作业？”

无论哪种方式，您都不会在等待期间消耗任何 CPU。有一些优点和缺点，但大多数都是微不足道的。从（粗略地和主观地）最重要的到最不重要的，cron 作业：

• 允许配置（例如更改计划），而无需编辑源代码。

• 需要配置才能工作。

• 意味着更少的代码 — — 意味着更少的错误，以及未来的读者需要理解的更少。

• 将在系统关闭后继续存在。

• 即使你的脚本因异常或信号退出也会再次触发。

• 如果错过 N 次预定间隔，则可能会触发 0、1 或 N 次（这没有指定，并且不同的 cron 实现会执行不同的事情），而不是保证 0 次。

• 有更好的机会处理系统时钟变化。

• 每次启动时，都要为进程启动、解释器启动等付出代价。

• 不会浪费页表和进程表空间，因为没有进程运行，也没有内存映射。

解决方案 2：

不，它不占用大量处理器。它使处理器处于空闲状态。

根据文档，它会暂停执行，这意味着它不是处理器密集型的。忙等待会占用大量处理器。