java inputstream 阻塞_Java InputStream阻塞读取

埃！ 不要放弃你的stream，但不要放弃。 我们在这里说串口通讯。 对于串行的东西，绝对期望-1读取可以被返回，但仍然期望在稍后的时间。 问题是，大多数人习惯于处理TCP / IP应该总是返回一个0，除非TCP / IP断开…然后是，-1是有意义的。 但是，使用串口时，数据stream不会延长一段时间，也不会有“HTTP Keep Alive”或TCP / IP心跳，或(在大多数情况下)没有硬件stream量控制。 但这个链接是实体的，仍然通过“铜”连接起来，仍然完美地生活着。

现在，如果他们说的是正确的，即：串行应该被closures-1，那么为什么我们必须注意的东西像OnCTS，pmCarroerDetect，onDSR，onRingIndicator等…哎，如果0意味着它的存在，-1表示不是，然后拧所有的检测function！ 🙂

您可能面临的问题可能在其他地方。

现在，具体到：

问：“似乎只有第二项赛事数据的尾部会显示出来，其余的则不见了。”

A：我会猜测你是在一个循环中，重新使用相同的byte []缓冲区。 第一条消息进入，没有显示在屏幕/日志/标准输出中(因为你在循环中)，那么你读取第二条消息，replace缓冲区中的第一条消息数据。 再一次，因为我猜测你没有存储多less读，然后确保以前面的读取量来抵消你的存储缓冲区。

问：“我最终改变了我的代码，以便当((aByte = read())> -1)存储字节时，当我得到一个事件时，我会调用if(inputStream.available()> 0)。

答：布拉沃…多数民众赞成那里的好东西。 现在，你的数据缓冲区在一个IF语句中，你的第二个消息不会打断你的第一个…实际上，它可能只是第一个地方的一个大的消息。 但现在，您将一眼就读完，保持数据不变。

C：“……种族条件…”

– 答：啊，好醇“赶上所有的景观山羊！ 比赛条件… :-)是的，这可能是一个竞争条件，事实上它可能是一直很好的。 但是，这也可能是RXTX清除标志的方式。 “数据可用标志”的清除可能不会像预期的那样快。 例如，任何人都知道读取VS readLine和清除缓冲区之间的区别，数据先前存储在这个区域中，并重新设置事件标志？ 我也没有。:-)我也没有find答案，但是…让我多讲几句话。 事件驱动的编程仍然有一些缺陷。 让我给你一个我最近不得不面对的现实世界的例子。

我有一些TCP / IP数据，可以说，20个字节。

所以我收到了接收数据的OnEvent。

我甚至在20个字节上开始“读”。

在我读完我的20个字节之前，我又得到了10个字节。

然而，TCP / IP看起来通知我，哦，看到这个标志还是SET，而不会再通知我。

但是，我完成阅读我的20个字节(可用()表示有20)…

…和最后10个字节保留在TCP / IP Q …因为我没有通知他们。

看，通知是错过的，因为国旗仍然设置…即使我已经开始阅读字节。 如果我完成了字节，那么标志将被清除，并且我将接收到接下来的10个字节的通知。

与你现在正在发生的事情完全相反。

所以是的，去一个IF可用()…做一个读取返回的数据长度。 然后，如果你是偏执狂，请设置一个计时器并再次调用available()，如果那里还有数据，则不要读取新的数据。 如果available()返回0(或-1)，那么放松…坐下来……等待下一个OnEvent通知。