所以我想到了阻塞和非阻塞 I/O 的想法。但我从概念和一些示例实现中了解到的是，我们在服务器端实现代码来实现代码的这种性质。
但现在我的问题是，如果（例如邮递员向服务器发送 HTTP 请求）请求必须等待服务器响应，那么非阻塞 I/O 的意义何在？ （如果我错了，请纠正我）或者整个概念只是为了增加服务器的吞吐量，而不是实际的异步性质。给客户。
例如，在我的一个项目中，我所做的是创建一个 post 请求，以在系统中创建一个请求进行处理，该请求将返回事务 ID，现在使用此事务 ID，我可以查询服务器以了解结果。
我可能听起来太天真，但这个概念让我很困惑。我不太清楚这个概念。请帮忙。
谢谢
请求必须等待服务器响应，那么非阻塞 I/O 有什么意义呢？
有一个混乱。等待响应和（非）阻塞 I/O 的关系非常松散。你总是必须等待回复。这就是您一开始提出请求的原因。但问题是：如何？
非阻塞 HTTP：“亲爱的服务器，这是我的请求，请处理它并向我发送响应，同时我要做点其他事情，比如计算 Pi 的第 n 位（我是个怪人） ”.
阻止 HTTP：“亲爱的服务器，这是我的请求，请处理它并向我发送响应，我将耐心等待它什么也不做”。
或者整个概念只是为了增加服务器的吞吐量，而不是实际的异步性质。给客户。
整个概念是能够在等待 I/O 的同时做其他事情。并在做到这一点的同时最大限度地减少扩展性不佳的线程的使用。
异步系统，即没有“我要空闲等待”部分的系统往往会以复杂性为代价表现得更好。
附注： 非阻塞 I/O 既可以在服务器端也可以在客户端使用。例如，浏览器中几乎所有 JS 引擎都是构建在某些异步引擎之上的。 JS 通常是单线程的，这意味着非阻塞 I/O 是实现任何并发性所必需的。
但是我从概念和一些示例实现中了解到的是，我们在服务器端实现代码来实现代码的这种性质。
您可以在执行非阻塞 UI 的任何位置实现代码。服务器的行为与客户端使用阻塞还是非阻塞 UI 无关，客户端的行为也与服务器使用阻塞还是非阻塞 UI 无关。
如果（例如邮递员向服务器发送 HTTP 请求）请求必须等待服务器响应，那么非阻塞 I/O 的意义何在？
这样您就不会浪费资源。
让我们首先考虑一个简单的控制台应用程序，该应用程序访问网络，然后对结果执行某些操作。在这种情况下，使用非阻塞 I/O 几乎没有什么好处，因为应用程序无论如何都会等待执行某些操作。
现在让我们考虑一个简单的控制台应用程序，它访问 50 个不同的 Web 资源并整理响应。现在，非阻塞 I/O 更有用，因为使用阻塞 I/O，它必须要么依次获取一个资源，要么启动 50 个线程。对于非阻塞 I/O，只需少量线程即可命中 50 个资源并及时响应每个返回的响应。
现在让我们考虑该应用程序的 GUI 版本，它希望保持对用户输入的响应，同时也在低功耗低内存设备上运行，在这些设备中，阻塞线程的成本更高。以上优点都增加了。
最后，考虑一个 Web 应用程序，它既与客户端进行 I/O，又作为数据库、文件系统和其他 Web 应用程序的客户端。它可能同时有多个请求，并且阻塞与客户端执行的 I/O 或与数据库、文件或其他应用程序执行的任何 I/O 都会消耗一个线程，这会限制可伸缩性它可以同时处理多少个请求。不阻塞 I/O 允许线程在 I/O 挂起时用于其他请求。
让我们以 Tomcat Servlet 上下文为例，这里非阻塞意味着，立即从 Servlet 上下文中解除线程的阻塞。 一旦请求到达 tomcat servlet 上下文，其中一个线程就会处理它并移交给工作线程并释放给它自己，以服务另一个线程。这样我们就可以理解它在服务器端线程的解锁性质。