Java中的非阻塞套接字写入与阻塞套接字写入相比 [英] Non-blocking socket writes in Java versus blocking socket writes

问题描述

为什么有人更喜欢阻止写入非阻塞写入？我的理解是，如果你想确保在写入方法返回后另一方获得TCP数据包，你只想要阻塞写入，但我甚至不确定是否可能。您必须刷新并且flush必须刷新底层操作系统写入套接字缓冲区。那么非阻塞套接字写入有什么缺点吗？有一个大的底层写入套接字缓冲在性能方面是一个坏主意吗？我的理解是，底层套接字写缓冲区越小，你就越有可能遇到慢/错误的客户端，并且在底层套接字缓冲区已满且isWritable（）返回false时，必须在应用程序级别中丢弃/排队数据包。

Why would someone prefer blocking writes over non-blocking writes? My understanding is that you would only want blocking write if you want to make sure the other side got the TCP packet once the write method returned, but I am not even sure that's possible. You would have to flush and flush would have to flush the underlying operating system write socket buffer. So is there any disadvantage of non-blocking socket writes? Does having a large underlying write socket buffer a bad idea in terms of performance? My understanding is that the smaller the underlying socket write buffer the more likely you will hit slow/buggy client and have to drop/queue packets in the application level while the underlying socket buffer is full and isWritable() is returning false.

推荐答案

我的理解是，如果你想确保另一方得到了返回写入方法后的TCP数据包

My understanding is that you would only want blocking write if you want to make sure the other side got the TCP packet once the write method returned

您的理解不正确。它不能确保。

Your understanding is incorrect. It doesn't ensure that.

阻塞写入阻塞，直到所有数据都被传输到套接字发送缓冲区，从那里异步传输到网络。如果读取器很慢，他的套接字接收缓冲区将填满，这最终会导致套接字发送缓冲区填满，这将导致阻塞写入阻塞，阻塞整个线程。非阻塞I / O为您提供了一种检测和处理这种情况的方法。

Blocking writes block until all the data has been transferred to the socket send buffer, from where it is transferred asynchronously to the network. If the reader is slow, his socket receive buffer will fill up, which will eventually cause your socket send buffer to fill up, which will cause a blocking write to block, blocking the whole thread. Non-blocking I/O gives you a way to detect and handle that situation.

这篇关于Java中的非阻塞套接字写入与阻塞套接字写入相比的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！