根据 Java api 文档,在 InputStream 中声明的 read() 方法描述如下:如果由于已到达流末尾而没有可用的字节,则值为 -1
根据 Java api文档 , read()
中声明的 InputStream
描述如下:
如果由于已到达流末尾而没有可用的字节,则返回值 -1。此方法将阻塞,直到输入数据可用、检测到流末尾或引发异常。
我有一个 while(true)
循环 read()
,当流中没有发送任何内容时,我总是得到 -1。这是意料之中的。
我的问题是什么时候会 read()
阻塞?因为如果它没有收到任何数据,它会返回 -1。我期望阻塞 read()
会等到收到数据。如果您已经到达输入流的末尾,难道不应该 read()
只是等待数据而不是返回 -1 吗?
或者 read()
仅当有另一个线程访问该流而您 read()
无法访问该流时才会阻塞?
这就引出了我的下一个问题。我曾经有一个事件监听器(由我的库提供),当数据可用时它会通知我。当我收到通知时,我会开始 while((aByte = read()) > -1)
循环存储字节。当我在很短的时间内收到两个事件并且并非所有数据都显示出来时,我感到很困惑。似乎只有第二个事件的数据的尾部会显示出来,其余数据都丢失了。
我最终修改了我的代码,这样当我收到事件时,我就开始 if(inputStream.available() > 0) while((aByte = read()) > -1)
存储字节。现在它工作正常,我的所有数据都显示出来。
有人能解释一下这种行为吗? 的 available()
方法 InputStream
据说返回在阻止下一个调用者(流的调用者?)之前可以读取的字节数。 即使我不使用, available()
我也希望第一个事件的读取只会阻止第二个事件的读取,但不会擦除或消耗太多的流数据。 为什么这样做会导致我的数据无法全部显示?
好吧,这有点乱,所以首先让我们澄清一下: InputStream.read()
阻塞与多线程无关。如果您有多个线程从同一个输入流读取数据,并且触发两个彼此非常接近的事件 - 每个线程都试图消费一个事件,那么您就会得到损坏:第一个读取的线程将获得一些字节(可能是所有字节),而当第二个线程被调度时,它将读取其余的字节。如果您计划在多个线程中使用单个 IO 流,则始终要 synchronized() {}
受到一些外部约束。
其次,如果你可以读取 InputStream
直到得到 -1,然后等待并稍后再次读取,则你使用的 InputStream 实现已损坏! 的契约 InputStream
明确规定, InputStream.read()
只有在没有更多数据可读取时才应返回 -1,因为已经到达流的末尾并且永远不会有更多数据可用 - 就像当你从文件中读取并到达末尾时一样(1).
“现在没有更多可用数据,请等待,您将获得更多数据”的行为是 read()
阻塞并且直到有可用数据(或引发异常)才返回。
FileInputStream
如果稍后将数据添加到文件中, read()
实现实际上可以读取超过 \'文件末尾\' 的数据,并在 -1
返回 InputStream
实现中唯一这样的情况(或者最坏的情况是 - 非常非常罕见)。如果您知道您使用 FileInputStream
并 期望您读取的文件添加了其他数据(一个常见的例子是跟踪日志文件),那么您应该考虑到这一点,但除此之外,这只是 API 的缺陷 InputStream
样式阻塞 IO API 并使用 java.io
非阻塞 IO API,那么 java.nio
您会更好