Java - 将 DataInputStream 与套接字一起使用，缓冲与否？
我正在编写一个简单的客户端/服务器应用程序，我发现使用 DataInputStream 读取数据非常方便，因为它允许您选择要读取的内容（无需自己将其从字节转换），但我想知道它是否会最好也将其包装在 BufferedInputStream 中，或者这是否只会增加不必要的开销？
我问的原因是因为我不知道直接从套接字流读取的成本有多高（当使用 BufferedInputStream 时，它只会从套接字流读取一次，然后使用 DataInputStream 从 BufferedInputStream 中读取多次）。
接收到的数据通常很小，大约 20-25 字节。
预先感谢您的任何答复！ ：D
I'm writing a simple client/server application and I found that using DataInputStream to read data was very convenient because it allows you to chose what to read (without having to convert it yourself from bytes), but I'm wondering if it would be best to wrap it in a BufferedInputStream too, or if that would just add unnecessary overhead?
The reason I'm asking is because I don't know how expensive it is to read directly from the socket stream (when using a BufferedInputStream it will just read once from the socket stream and then multiply times from the BufferedInputStream using DataInputStream).
The data received is usually pretty small, around 20-25 Bytes.
Thanks in advance for any answer! :D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DataInputStream 没有缓冲，因此对 DataInputStream 对象的每个读取操作都将导致对底层套接字流进行一次或多次读取，这可能会导致多个系统调用（或同等形式）。
系统调用通常比常规方法调用昂贵 2 到 3 个数量级。缓冲流的工作原理是减少系统调用的数量（理想情况下为 1），但代价是添加额外的常规方法调用层。通常，使用缓冲流会将
N系统调用替换为1系统调用和N额外方法调用。如果N（即流方法调用与系统调用的比率）大于1，您就赢了。因此，仅在套接字流和
DataInputStream之间放置BufferedInputStream的情况不是“胜利” ” 是：听起来这些不适用于您的情况。
此外，即使它们确实适用，当您不需要时，使用 BufferedInputStream 的开销也相对较小。相比之下，当您确实需要时，不使用 BufferedInputStream 的开销可能会很大。
最后一点，实际读取的数据量（即消息的大小）与缓冲与非缓冲难题几乎无关。真正重要的是数据的读取方式；即您的应用程序将进行的
read...()调用序列。A DataInputStream is not buffered, so each read operation on a
DataInputStreamobject is going to result in one or more reads on the underlying socket stream, and that could result in multiple system calls (or the equivalent).A system call is typically 2 to 3 orders of magnitude more expensive than a regular method call. Buffered streams work by reducing the number of system calls (ideally to 1), at the cost of adding an extra layer of regular method calls. Typically using a buffered stream replaces
Nsyscalls with1syscall andNextra method calls. IfN(i.e. the ratio of stream method calls to syscalls) is greater than1, you win.It follows that the only cases where putting a
BufferedInputStreambetween the socket stream and theDataInputStreamis not a "win" are:read...()call and that can be satisfied by a single syscall,read(byte[] ...)calls, orIt sounds like these don't apply in your case.
Besides, even if they do apply, the overhead of using a
BufferedInputStream*when you don't need to is relatively small. By contrast, the overhead of not using aBufferedInputStreamwhen you do need to can be huge.One final point, the actual amount of data read (i.e. the size of the messages) is pretty much irrelevant to the buffered versus unbuffered conundrum. What really matters is the way that data is read; i.e. the sequence of
read...()calls that your application will make.一般的观点是，底层流上的单独读取非常慢，因此缓冲几乎总是更快。然而，对于如此小的数字（20-25 字节），分配缓冲区的成本可能与进行这些单独读取的成本类似（一旦考虑内存分配和垃圾收集）。不幸的是，找出答案的唯一方法就是测试它并看看。
您说收到的数据通常很小：您预计多久会收到较大的消息？如果您偶尔在无缓冲的流上收到大消息，这将是一个严重的瓶颈。
我建议您运行一些计时测试，看看缓冲是否对您的情况产生影响。或者，不要费心进行计时测试，而只使用缓冲区。如果消息大小将来发生变化，那么这将减少以后的维护。
The general wisdom is that individual reads on the underlying stream are very slow so buffering almost always is faster. However, for such small numbers (20-25 bytes) it might be that the cost of allocating the buffer is similar to the cost of making those individual reads (once you consider memory allocation and garbage collection). Unfortunately, the only way to find out is to test it and see.
You say that the data received is usually small: how often do you expect larger messages? That will be a significant bottleneck if you receive occasional large messages on an unbuffered stream.
I'd suggest that you run some timing tests and see if buffering makes a difference in your case. Or, don't bother with timing tests and just use a buffer. If the message size changes in the future then this will reduce maintenance later on.