while(1) 和阻塞调用之间的性能答案

【问题标题】：Performance between while(1) and blocking callwhile(1) 和阻塞调用之间的性能
【发布时间】：2016-08-19 07:46:31
【问题描述】：

我有一个小应用程序使用来自 RabbitMQ 的消息。

目前它在一个 while(1) 循环中，它调用“出队”并在那里永远等待一条消息，然后处理该消息。

所以我在想阻塞调用“出队”是一个好主意，还是立即出队（没有立即返回）不会更好，甚至可能是超时的“出队”。迭代当然会更多。

谢谢

【问题讨论】：

只有在预期的等待时间“非常短”时才应该使用旋转等待。您实际上是在让 CPU 无所事事。如果这样做比将上下文切换到另一个线程更便宜，那么这可能是一个好主意。如果你等待很长时间，它不会。如果不了解您的案例，很难给出好的建议。你有这些方法的异步版本吗？
不幸的是它没有异步。那会非常好。
@Pintac 编写异步包装器非常容易。显然必须牺牲一个 I/O 线程。但这在 EDA（事件驱动架构，例如 node.js）中是正常/可接受和常见的。因此，异步包装器的想法更多是关于编程风格和易用性，而不是性能或资源占用。
是的，如果这对我的系统来说是一个非常巨大/重要的部分，我很可能会做一个，但看到这是一项小型维护任务，它真的不值得付出努力......

【解决方案1】：

这是一个经典问题。您可以做的最好的事情是使用带有超时的阻塞Dequeue()，这样可以处理的不仅仅是 RabbitMQ 消息。例如：

应根据您的期望设置超时。对于某些系统信号，在进程被抛到水面之前会给出非常严格的超时。对于控制台应用程序，人类用户不会注意到 150 毫秒的超时，但在他们看来，它仍然接近实时。

如果您不阻塞也不使用超时，CPU 将消耗不必要的资源以尽可能快地循环，而没有任何好处。仅当时间非常重要时，才建议这样做。但是你也不会使用 RabbitMQ。

编辑：关于超时的更多信息

1 秒超时不意味着在 1 秒内接收到消息。消息在到达时仍会立即得到处理。超时意味着 OTHER 任务最多延迟 1 秒（平均延迟是超时的一半，因此为 0.5 秒）。

【讨论】：