当使用 http 客户端库向服务发出同步请求时,线程会被阻塞,直到返回数据。那么在同步http请求中使用非阻塞io有什么好处吗?
用例:使用 Spring MVC 开发的 Web 应用程序。对于某些请求,会对 REST 服务进行同步调用。使用使用 NIO 调用服务的 HttpClient 库是否有利?Jetty HttpClient使用非阻塞 IO。我不清楚 HttpComponents 的HttpClient是否支持 NIO。
当使用 http 客户端库向服务发出同步请求时,线程会被阻塞,直到返回数据。那么在同步http请求中使用非阻塞io有什么好处吗?
用例:使用 Spring MVC 开发的 Web 应用程序。对于某些请求,会对 REST 服务进行同步调用。使用使用 NIO 调用服务的 HttpClient 库是否有利?Jetty HttpClient使用非阻塞 IO。我不清楚 HttpComponents 的HttpClient是否支持 NIO。
假设您实现了某种服务于多个客户端的服务。您需要通过 I/O 操作(文件访问、网络通信等)实现一定程度的并行性。否则,单个客户端可以阻止其他客户端。您现在有两个选择:
您可以生成多个线程,每个线程都使用阻塞 I/O 操作。
您使用单个线程(或很少)并使用非阻塞 I/O 操作。
使用非阻塞 I/O 实现解决方案通常要困难得多,因为您必须自己管理每个客户端的上下文。当您为每个客户端使用专用线程时,上下文自然是给定的(线程上下文 = 客户端上下文)。
如果您有大量慢速客户端,则非阻塞 I/O 值得额外的实现工作,因为您可以使用少量线程来处理它们。如果您为每个客户端使用一个线程,他们主要会坐在那里等待并且仍然会使用大量内存。
如果你不是在实现一个服务而是一个简单的应用程序,那么非阻塞 I/O 肯定不值得。
更新:如果我正确理解用例,您有一个 Web 应用程序,它不仅为 Web 客户端提供网页,还需要执行 REST 请求来为 Web 客户端提供服务。因此,如果您有大量并发客户端(几千个或更多)并且 REST 请求需要很长时间(几秒钟),那么非阻塞 I/O 可能是有意义的。但是您的 Web 服务器将需要支持异步操作,以便您可以将线程返回给服务器,直到 REST 请求完成。Servlert 3.0 规范引入了异步操作。因此,您需要一个最新的 Web 服务器,例如 Tomcat 7。