asio什么时候应该使用多线程？答案

【问题标题】：When should multithreading be used with asio?asio什么时候应该使用多线程？
【发布时间】：2019-02-07 14:52:20
【问题描述】：

我正在编写一个使用 Boost asio 的网络库，并且对是否应该使用单独的线程来运行 io_service 感到困惑。

我目前有一个包含所有 asio 工作的类。它有一个 io_service，一个 socket 等，并使用 async_read 和 async_write 方法与远程服务器通信。该类公开了读取和写入方法，以允许用户与远程服务器进行通信。

这个类然后被其他类调用，这些类使用它的读/写方法向远程服务器发送和接收数据。在某些情况下，会出现从服务器读取/写入数据的链式调用，直到调用最终用户提供的回调以传递计算的最终结果。

我现在正在尝试实现一个连接池，并且想知道是否需要一个线程池：对远程服务器的所有读取和写入都使用异步方法，在最终用户提供的回调之前，没有任何读取后处理涉及阻塞调用.如果不需要单独的线程池，让一系列连接对象同时运行不好吗？

【问题讨论】：

【解决方案1】：

如果您只有一个线程，那么当您获取数据并对其进行处理时，您将阻塞任何其他调用。当然，如果您在async_read 或async_write 中所做的唯一事情是启动下一个异步调用，那么io_service 线程总是在等待新数据到达，并填充相关的连接底层数据结构.一个线程没问题。

但是您可能有某种与读/写数据交互的处理，这是您可以与线程池并行化的部分。所以问题是：这个处理所消耗的时间比例有多大？是服务器的瓶颈（延迟和带宽）吗？

我过去在这里看到过不同的案例。一个案例是一个简单的服务器处理一个任务列表并将数据分派给客户端。它不需要线程，我不关心延迟，因为客户端只会不时出现，没有瓶颈。然后我遇到了另一个需要快速处理所有内容的情况，在这种情况下，我使用了线程池。

所以真正的问题是：瓶颈在哪里？

【讨论】：

读取或写入时没有阻塞，处理接收到的数据非常快，毫秒级。有一个带有一个 io_service、多个连接对象且没有线程的连接池仍然有意义吗？
在那种情况下，我会说单线程就足够了。在这种情况下，通过线程化你可能看不到任何性能改进（但你可以尝试测量，我可能错了）。是的，始终使用连接池，以便在每个连接上正确存储数据。
是否有关于何时使用 MT 的规范规则？
不，没有规则。只有测量才能提示机器翻译需求，然后进行算法分析。