许多库包装了一些外部通信。无论是类 REST 的 API、消息队列、数据库、邮件服务器还是其他东西。因此,您必须有一些超时时间——用于连接、读取、写入或空闲。遗憾的是,许多库的默认超时设置为“0”或“-1”,这意味着无穷大。
这是一个非常无用甚至有害的默认设置。没有一个实际用例让您希望永远等待资源。并且有很多情况会发生这种情况,例如另一端卡住了。在过去的 3 个月里,我有 2 个库的默认超时为“无穷大”,最终导致生产问题,因为我们忘记了正确配置它们。有时您甚至看不到问题,直到线程池耗尽。
永远不要将“Inifinty”作为默认超时。因为,您的库会导致许多生产问题。还要注意,有时底层的 HTTP 客户端(或 Socket)没有合理的默认值——在包装它时修复它仍然是你的工作。
您应该提供什么默认值?合理的。5秒可以吗?您可能说您不想对用户强加任意超时。在这种情况下,我有一个更好的建议:
明确要求构建“客户端”超时(因为这些库通常是某些外部系统的客户端)。例如Client.create(url, credentials, timeout)
。如果没有提供超时,则失败。这使得客户端的用户积极考虑他们的用例什么是好的超时 - 不强加任何东西,最重要的是 - 不会冒生产中连接卡住的风险。此外,您仍然可以向他们提供“默认”选项,但仍让他们明确选择它。例如:
Client client = ClientBuilder.create(url) .withCredentials(credentials) .withTimeouts(Timeouts.connect(1000).read(1000)) .build(); // OR Client client = ClientBuilder.create(url) .withCredentials(credentials) .withDefaultTimeouts() .build();
上面的构建器应该要求设置“timeout”,如果两个方法都没有被调用,则应该失败。即使你不提供这些选项,至少有一个指定超时的好方法——一些库需要反射来设置其底层客户端的超时。
我相信这是那些看起来很小但在现实世界中会导致很多问题的问题之一。它可以(并且应该)由库/客户端设计者解决。
但由于情况并非总是如此,我们必须确保每次使用 3rd 方库时都配置超时。