了解 AWS 开发工具包 Java 2.x（异步与同步）HTTP 客户端

问：

AWS Java 2.x 开发工具包提供了许多不同的 http 客户端替代方案。其中两个是：

1. 基于 Apache 的同步 HTTP 客户端
2. AWS 基于 CRT 的异步 HTTP 客户端

为了帮助我了解 Sync 和 Async 之间的区别，我试图了解此处找到的 AWS 文档中描述的差异。

例如，在浏览他们关于使用哪种的建议时，我发现以下内容非常奇特：

建议使用基于 Apache 的同步 HTTP 客户端，以实现“低延迟 高吞吐量“，而基于 CRT 的 AWS 异步 HTTP 客户端是 建议用于“低延迟的高吞吐量”。

简而言之，基于 Apache 的同步 HTTP 客户端到底如何比异步 HTTP 客户端具有更低的延迟？我希望延迟基于网络延迟，因此您使用哪个客户端（无论是同步还是异步）完全无关紧要。

另外，异步客户端怎么可能比同步 HTTP 客户端具有更高的吞吐量，这对我来说也没有意义？我的预期恰恰相反，因为同步客户端将忙于等待响应可用，而异步客户端将在此期间执行其他操作，因此可能还没有准备好在响应到达时处理响应。

以下是上述想法的更多内容。

我的理解是，高吞吐量和低延迟是负相关的。如果增加一个，通常会减少另一个，反之亦然。当然，可能还有其他因素可能会降低吞吐量，同时保持延迟稳定。尽管如此，我看不出任何一个客户端将如何影响网络吞吐量或延迟。

对我来说，运行包装在 promise 中的基于 Apache 的同步 HTTP 客户端与直接使用异步 HTTP 客户端之一（例如 netty 或基于 CRT 的异步客户端）有什么区别，这对我来说有点令人困惑 - 我相信我理解这些差异，但让我在下面说明。

它们都使用线程池（至少，如果您使用的是基于 Apache 的同步客户端，则用于同步），它们都必须等待响应。

我猜想，当使用基于 Apache 的同步 HTTP 客户端创建 HTTP 客户端请求时，它通常会从线程池中抽取一个线程，使用该线程创建 HTTP 连接，发起请求，然后忙于等待响应，该响应将不断消耗 CPU 时间，以便线程继续轮询以查看响应是否可用。

同时，对于异步 HTTP 客户端，它遵循与上述相同的过程，只是它不忙于等待响应，它会在此期间将该线程用于其他目的，或者如果没有找到其他目的，它将在不消耗 CPU 时间的情况下休眠，直到响应传入;响应将通过某种操作系统机制触发 JVM 唤醒休眠线程以处理响应。

根据我的理解，我不明白基于 Apache 的同步 HTTP 客户端如何比基于 AWS CRT 的异步 HTTP 客户端具有更低的延迟？我不明白基于 CRT 的 AWS 异步 HTTP 客户端如何具有更高的吞吐量？在我看来，两者之间的区别主要决定了程序使用 CPU 的效率。