Java 中的非阻塞套接字写入与阻塞套接字写入

发布于 2024-12-15 00:12:56 字数 268 浏览 1 评论 0原文

为什么有人更喜欢阻塞写入而不是非阻塞写入?我的理解是,如果您想确保另一方在 write 方法返回后收到 TCP 数据包,则只需要阻止写入,但我什至不确定这是否可能。您必须刷新,并且刷新必须刷新底层操作系统写入套接字缓冲区。那么非阻塞套接字写入有什么缺点吗?就性能而言,拥有大型底层写入套接字缓冲区是否是一个坏主意?我的理解是,底层套接字写入缓冲区越小,您就越有可能遇到缓慢/有问题的客户端,并且当底层套接字缓冲区已满且 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

怎会甘心 2024-12-22 00:12:56

我的理解是,如果你想确保对方在 write 方法返回后收到 TCP 数据包,你只需要阻塞 write

您的理解是不正确的。它并不能确保这一点。

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

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.

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.

柏拉图鍀咏恒 2024-12-22 00:12:56

非阻塞写入的问题是,如果写入不完整,您可能无事可做。您最终可能会得到像

// non-blocking write
while(bb.remaining() > 0) sc.write(bb);

OR

// blocking write
sc.write(bb);

这样的循环。第一个循环可能会消耗 CPU,而第二个循环可能更理想。

最大的问题是读取。一旦您决定要阻塞读取还是非阻塞读取,您的写入就必须相同。不幸的是,没有办法让它们不同。如果你想要非阻塞读取,你就必须有非阻塞写入。

The problem with non blocking writes is that you may not have anything useful to do if the write is incomplete. You can end up with loops like

// non-blocking write
while(bb.remaining() > 0) sc.write(bb);

OR

// blocking write
sc.write(bb);

The first can burn CPU and the second might be more desirable.

The big problem is reads. Once you decide whether you want blocking or non-blocking reads, your writes have to be the same. Unfortunately there is no way to make them different. If you want non-blocking reads, you have to have non-blocking writes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文