性能:I/O操作在一个循环中

"看情况。"

如果网络设备产生稳定的数据流，那么有一个线程专门用于同步服务它是有意义的。线程阻塞直到数据可用，然后读取和处理数据。该线程可以在必要时通知主线程。

如果设备不经常产生数据，那么使用异步请求可能更有意义。在主线程中发出一个异步读调用，然后继续你的工作。当数据可用时，则由异步回调读取并进行适当的处理，并发出一个新的异步读取。

这是我使用的一般规则:大量数据，然后专用一个线程。不频繁的数据，使用异步。这不是一个硬性规定，但这是我开始的地方。

无论哪种方式都会对性能产生影响。这是一个权衡的问题。持久线程将在其整个生命周期中消耗资源(主要是堆栈空间，以及线程进程使用的任何数据)。如果线程花费大部分时间等待输入，这不是一个非常有效的资源使用。

另一方面，发出异步读请求需要一些非零的时间。如果您期望的数据频率不高(例如，每秒不超过一次)，那么这些异步读请求所涉及的开销可能无关紧要。但是，如果您有连续的数据流，并且每秒发出数百或数千个异步读请求，那么开销将影响性能。当您执行如此多的读请求时，您实际上有一个专门的线程来处理输入，因此您不妨简化程序并创建一个持久线程。

是的，它有影响:

创建新线程消耗内存和初始化线程的时间
• 线程管理(sleep/wake)
• 线程同步消耗读数据。

如果可能的话，你最好实现异步读取。这是一个更优雅的解决方案。

虽然很多应用程序使用你描述的方法，没有显著的性能问题，所以这是一个可能的解决方案和主要问题不是性能在这里我想说(如果你不为每一个新的文件或用户每秒创建一个新的线程)