是否总是需要一个单独的“写入器”线程（在套接字读取器/文件写入器客户端中）？

Question

我有一些客户端代码从套接字读取（通过输入流）并在循环中写入文件（通过 BufferedWriter）：

dataInStream = new BufferedInputStream(dataSocket.getInputStream());
outputFile = new BufferedWriter(new FileWriter(filename));
byte bytes[] = new byte[64];
Message msg = new Message();
int bytesRead = 0;
while (true) {                
   bytesRead = dataInStream.read(bytes, 0, 64);
   // create a message from the raw data...
   msg.parse(bytes);
   // write it to the file as a String
   outputFile.write(msg.toString());
   outputFile.flush();
}

（显示一般流程的简化代码 - 我只在需要添加额外的编写器线程时才对学习感兴趣）

在什么时候（数据速率方面）我可能需要将文件写入操作拆分到另一个线程（即“写入器”）中，在读取器和写入器之间使用类似 ConcurrentLinkedQueue线程？

我的要求消息速率很低（即 1400 字节消息，最多每秒 10 条消息）

我对吞吐量进行基准测试的测试代码表明它可以轻松处理 150000 字节/秒。 由于数据速率（无论结果如何）是恒定的，写入器是否可以阻塞足够长的时间以导致读取器的数据丢失？

或者总是有一个阅读器和一个作者线程只是一种好习惯？

Answer 1

在什么时候（数据速率方面）我可能需要将文件写入操作拆分到另一个线程（即“写入器”）

您应该仅在遇到性能问题或分析器告诉您这是个好主意时开始优化您的代码（使其更复杂）。

或者总是有一个读者和一个作者线程只是一个好习惯？

这是一个很好的做法，没有其他信息。但是在您的情况下，您知道数据要求，因此只有在您期望大量吞吐量或者您期望在磁盘端受到 IO 限制时才应该这样做。

我的要求消息速率很低（即 1400 字节消息，最多每秒 10 条消息）

这并不足以保证额外的代码复杂性

写入器是否会阻塞足够长的时间以导致读取器丢失数据？

在大多数情况下，本地磁盘 IO 会比网络更快。有可能遇到这种情况，但我认为这不是很常见。内核在套接字上为您提供大量缓冲，如果您溢出内核缓冲区，TCP/IP 协议将重新传输，因此即使您 do 阻塞很长时间，您也不会丢失数据。