Java InputStream阻塞读取 [英] Java InputStream blocking read

问题描述

根据java api， InputStream.read（）被描述为：

According to the java api, the InputStream.read() is described as:

如果没有字节可用，因为已达到流的
结尾，则返回
，返回值-1。此方法
阻塞，直到输入数据可用，
检测到流的末尾，或
抛出异常。

If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.

我有一个而（true）循环执行读取，当通过流发送任何内容时，我总是得到-1。这是预期的。

I have a while(true) loop doing a read and I always get -1 when nothing's sent over the stream. That's expected.

我的问题是什么时候会读取（）阻止？因为如果它没有得到任何数据，它返回-1。我希望阻塞读取等到收到数据。如果你已到达输入流的末尾，不应该读取（）只是等待数据而不是返回-1？

My question is when would read() ever block? Since if it doesn't get any data it returns -1. I would expect a blocking read to wait until data is received. If you've reached the end of the input stream, shouldn't read() simply wait for data instead of returning -1?

或者read（）只是阻止如果有另一个线程访问流并且你的read（）无法访问流？

Or does read() only block if there's another thread accessing the stream and your read() cannot access the stream?

这引出了我的下一个问题。我曾经有过事件监听器（由我的库提供），当数据可用时会通知我。当我收到通知时，我会调用 while（（aByte = read（））> -1）存储字节。当我在非常接近的时间内收到两个事件并且我的所有数据都没有被显示时，我感到很困惑。似乎只会显示第二个事件数据的尾端而其余部分都会丢失。

Which leads me to my next question. I used to have event listener (provided by my library) that would notify me when data is available. When I was notified I would call while((aByte = read()) > -1) store the byte. I was puzzled when I'd get TWO events in very close time proximity and not all my data was being displayed. It seemed like only the tail end of the second event's data would be displayed and the the rest was missing.

我最终改变了我的代码，这样当我收到一个事件时如果（inputStream.available（）> 0），则调用而（（aByte = read（））> -1）存储该字节。现在它正常工作，我的所有数据都显示出来了。

I eventually changed my code so that when I get an event I'd called if(inputStream.available() > 0) while((aByte = read()) > -1) store the byte. Now it worked properly and all my data was displayed.

有人可以解释这种行为吗？据说 InputStream.available（）返回阻塞下一个调用者（流的？）之前可以读取的字节数。即使我不使用.available（），我希望第一个事件的读取只是阻止第二个事件的读取，但不会擦除或消耗过多的流数据。为什么这样做会导致我的所有数据都不显示？

Can someone explain this behavior? The InputStream.available() is said to return the number of bytes you can read before blocking the next caller (of the stream?). Even if I don't use .available() I would expect the read of the first event to just block the read of the second event, but not erase or consume too much stream data. Why would doing this cause not all of my data to be displayed?

推荐答案

<$ c的某些实现的基础数据源$ c> InputStream 可以表示已经到达流的末尾，并且不再发送数据。在接收到该信号之前，对这种流的读操作可能会阻塞。

The underlying data source for some implementations of InputStream can signal that the end of the stream has been reached, and no more data will be sent. Until this signal is received, read operations on such a stream can block.

例如，来自 Socket 套接字的 InputStream 将阻止而不是返回EOF，直到收到设置了FIN标志的TCP数据包。当从这样的流接收到EOF时，可以确保在该套接字上发送的所有数据都已被可靠地接收，并且您将无法再读取任何数据。 （如果阻塞读取导致异常，另一方面，某些数据可能已丢失。）

For example, an InputStream from a Socket socket will block, rather than returning EOF, until a TCP packet with the FIN flag set is received. When EOF is received from such a stream, you can be assured that all data sent on that socket has been reliably received, and you won't be able to read any more data. (If a blocking read results in an exception, on the other hand, some data may have been lost.)

其他流，如来自原始文件或串行端口的流，可能缺少类似的格式或协议，以表明没有更多的数据可用。当没有数据当前可用时，这些流可以立即返回EOF（-1）而不是阻塞。但是，如果没有这样的格式或协议，您无法确定对方何时完成发送数据。

Other streams, like those from a raw file or serial port, may lack a similar format or protocol to indicate that no more data will be available. Such streams can immediately return EOF (-1) rather than blocking when no data are currently available. In the absence of such a format or protocol, however, you can't be sure when the other side is done sending data.

关于你的第二个问题，听起来你可能遇到了竞争条件。没有看到有问题的代码，我猜测问题实际上在于你的显示方法。也许第二次通知显示的尝试在某种程度上破坏了第一次通知期间所做的工作。

With regard to your second question, it sounds like you may have had a race condition. Without seeing the code in question, I'm guessing that the problem actually lay in your method of "display". Perhaps the attempt to display by the second notification was somehow clobbering the work done during the first notification.

这篇关于Java InputStream阻塞读取的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！