为什么超时值这么小？

Question

我不确定这是否是一个纯粹的 stackoverflow 相关问题。它与一般设计实践有关。由于我想不出另一个相关的堆栈交换站点，所以在这里发布。

在将异步调用转换为同步调用的一般设计实践中，我们使用超时并等待结果。虽然从响应性的角度来看，这可能不是一个好的实践，但它确实使实现更容易。

我见过很多这样的实现，并且经常注意到开发人员倾向于给出一个非常小的超时值。我可以理解人们在这样做时可能需要一个响应式系统。但是我见过的许多应用程序都是数据非常关键的应用程序，其中数据丢失非常严重。因此，最好等待更多时间并尝试获取尽可能多的数据，而不是提前超时并向用户提供错误消息。现在，服务器无法提供数据或客户端无法访问服务器等情况已经很少见了。在这些情况下，我预计此类等待会出现很大的超时。毕竟，这些超时并不意味着等待一定会持续到给定的超时值；超时值只是一个上限。所以，我一直在这里主张更高的价值。但是我看到在越来越多的地方使用低值，现在我很困惑，如果这种做法真的有其他我不理解的地方。

所以，我的问题是：除了需要响应性来实现非常小的等待超时之外，还有什么论据吗？

Answer 1

一如既往，正确的决定取决于现实生活中的数据。 超时应与成功完成操作通常所需的时间成正比。

例如，发送 UDP 消息可能需要 1 到 50 毫秒，因此 100 毫秒的超时是非常合理的，但是通过网络复制文件可能需要几分钟或更长时间，因此 100 毫秒的超时是可笑的。

短暂停和长暂停各有利弊，因此需要权衡取舍。较长的超时使用更多的资源（任务、线程、内存等）来完成相同的工作量，而正如您所提到的，较短的超时可能会导致数据丢失。

总之，您需要设置一个听起来合理的可配置超时，然后确定您是在生产中超时还是在其他方面超时，并相应地进行校准。