Чтение блокирования Java InputStream

Базовый источник данных для некоторых реализаций InputStream может сигнализировать, что конец потока был достигнут, и больше данных не будет отправлено. Пока этот сигнал не получен, операции чтения на таком потоке могут заблокироваться.

, Например, InputStream от Socket сокет заблокируется, вместо того, чтобы возвратить EOF, пока пакет TCP с набором флага FIN не будет получен. Когда EOF получен от такого потока, Вас можно уверить, что все данные, отправленные на том сокете, были надежно получены, и Вы не будете в состоянии считать больше данные. (Если блокирование считало результаты в исключении, с другой стороны, некоторые данные, возможно, были потеряны.)

Другие потоки, как потоки из необработанного файла или последовательного порта, могут испытать недостаток в аналогичном формате или протоколе, чтобы указать, что больше данных не будет доступно. Такие потоки могут сразу возвратить EOF (-1) вместо того, чтобы блокироваться, когда никакие данные не в настоящее время доступны. В отсутствие такого формата или протокола, однако, Вы не можете быть уверены, когда другая сторона сделана, отправив данные.

<час>

Относительно Вашего второго вопроса, это кажется, что у Вас, возможно, было состояние состязания. Не видя рассматриваемый код, я предполагаю, что проблема на самом деле заключается в Вашем методе "дисплея". Возможно, попытка отобразиться вторым уведомлением так или иначе ударяла работу, сделанную во время первого уведомления.

Это возвращается-1, если это - конец потока. Если поток все еще открыт (т.е. сокетное соединение), но никакие данные не достигли стороны чтения (сервер является медленным, сети является медленным...), чтение () блоки.

Вы не должны называть доступным (). Мне нелегко понимать Ваш дизайн уведомления, но Вам не нужны никакие вызовы кроме чтения () самого. Доступный метод () там для удобства только.

Хорошо, это - определенная путаница, которой позволяет поэтому первая вещь, разрешают это: InputStream.read() блокирование не имеет никакого отношения к многопоточности. Если у Вас есть несколько потоков, читающих из того же входного потока, и Вы инициировали два события очень друг близко к другу - где каждый поток пытается использовать событие тогда, Вы получили бы повреждение: первый поток, который будет читать, получит некоторые байты (возможно все байты) и когда второй поток будет запланирован, он считает остальную часть байтов. Если Вы планируете использовать единственный поток IO в более тогда одном потоке, всегда synchronized() {} на некотором внешнем ограничении.

117-секундный, если можно читать из Вашего InputStream, пока Вы не добираетесь-1 и затем ожидаете и может читать снова позже, тогда реализация InputStream, которую Вы используете, повреждается! Контракт для InputStream ясно состояния, которые InputStream.read() должны только возвратиться-1, когда больше нет данных для чтения, потому что конец всего потока был достигнут и больше никаких данных, КОГДА-ЛИБО будут доступны - как то, когда Вы будете читать из файла, и Вы достигаете конца.

поведение для "больше данных доступно теперь, ожидайте, и Вы доберетесь, больше", чтобы read() заблокировался, и не возвращаются, пока нет некоторые доступные данные (или исключение выдается).

Ага! Не отказывайтесь пока от своего стрима Jbu. Здесь мы говорим о последовательной связи. Для последовательных данных абсолютно ожидается, что -1 может / будет возвращаться при чтении, но все же ожидать данных в более позднее время. Проблема в том, что большинство людей привыкли иметь дело с TCP / IP, который всегда должен возвращать 0, если TCP / IP не отключен ... тогда да, -1 имеет смысл. Однако с последовательным интерфейсом нет потока данных в течение продолжительных периодов времени, и нет «HTTP Keep Alive», или пульса TCP / IP, или (в большинстве случаев) нет аппаратного управления потоком. Но соединение является физическим, и все еще соединено «медью» и все еще прекрасно работает.

Теперь, если то, что они говорят, правильно, то есть: последовательный порт должен быть закрыт при -1, тогда почему мы должны следить за такие вещи, как OnCTS, pmCarroerDetect, onDSR, onRingIndicator и т. д. Черт возьми, если 0 означает, что он есть, а -1 означает, что его нет, тогда к черту все эти функции обнаружения! : -)

Проблема, с которой вы можете столкнуться, может быть где-то в другом месте.

Теперь перейдем к деталям:

Q: «Казалось, что будет отображаться только конец данных второго события, а все остальное будет отсутствует. "

A: Я собираюсь предположить, что вы были в цикле, повторно используя тот же буфер byte []. Приходит 1-е сообщение, еще не отображается на экране / log / std out (потому что вы находитесь в цикле), затем вы читаете 2-е сообщение, заменяя данные 1-го сообщения в буфере. Опять же, потому что я собираюсь предположить, что вы не сохраняете, сколько вы читаете, а затем удостоверились, что смещаете буфер вашего хранилища на предыдущий объем чтения.

Q: «В конце концов я изменил свой код так, чтобы получить событие, которое я назвал if (inputStream.available ()> кто-нибудь знает разницу между чтением VS readLine в отношении очистки буфера, в котором ранее хранились данные, и повторной установкой флага события? Я тоже :-) И я пока не могу найти ответ ... но ... позвольте мне поболтать еще несколько предложений. Программирование, управляемое событиями, по-прежнему имеет некоторые недостатки. Позвольте мне привести реальный пример, с которым мне пришлось иметь дело недавно.

• У меня есть некоторые данные TCP / IP, скажем, 20 байтов.
• Итак, я получаю событие OnEvent для полученных данных.
• Я начинаю «чтение» даже с 20 байтов.
• Прежде чем я закончу читать свои 20 байтов ... я получаю еще 10 байтов.
• TCP / IP, однако, пытается уведомить меня, о, видит, что флаг все еще установлен, и больше не будет уведомлять меня.
• Тем не менее, я дочитал свои 20 байт (available () сказал, что их было 20) ...
• ... и последние 10 байтов остаются в TCP / IP Q ... потому что я не был уведомлен о них.

Видите ли, уведомление было пропущено, потому что флаг все еще был установлен ... хотя я начал читать байты. Если бы я закончил байты, тогда флаг был бы сброшен, и я получил бы уведомление для следующих 10 байтов.

Полная противоположность тому, что происходит с вами сейчас.

Так что да, используйте IF available () ... выполнить чтение возвращенной длины данных. Затем, если вы параноик, установите таймер и снова вызовите available (), если там все еще есть данные, затем выполните чтение новых данных. Если available () возвращает 0 (или -1), расслабьтесь ... расслабьтесь ... и дождитесь следующего уведомления OnEvent.