Android: Насколько надежным является InputStream.read() и его «-1» возврат?

Question

Мой вопрос связан с методом InputStream.read() - программирование сокетов.

Каждый найденный источник утверждает, что когда сервер или клиент закрывают соединение, возвращается «-1».

Но, «что если», просто говоря, «что, если» соединение будет закрыт, но чтения() не возвращает «-1»? Мы полагаемся на чужой код. Причина, по которой я волнуюсь, состоит в том, что для того, чтобы читать вход удаленного конца, нужно создать бесконечный цикл, и мне всегда казалось, что он должен держаться подальше от бесконечных циклов. С Java, однако, похоже, что у меня нет выбора! Вот пример:

int b = 0; 
    while (true) 
    { 
     b = inputStream.read() 
     if (b == -1) break; // connection closed 
    } 

или

while (b > -1) 
b = inputStream.read() 

Что если что-то происходит, и -1 никогда не станет правдой? Один из них закончится бесконечным циклом, повышающим температуру чьего-то устройства и потерявшим процессорные циклы! Как можно быть уверенным?

Литература: [http://developer.android.com/reference/java/io/InputStream.html#read%28%29][1] и [http://docs.oracle.com/javase/ 6/docs/api/java/io/InputStream.html # read% 28byte [],% 20int,% 20int% 29] [2]

Я хочу иметь отказоустойчивую проверку. То, что я сделал в цикле, также проверяет, стал ли сокет равным нулю, и если да, то разрыв цикла.

while (b > -1) 
    { 
     b = inputStream.read() 

     if (socket == null) break; 
     if (outputStream == null) break; 
    } 

Что еще я могу сделать, чтобы обеспечить существование цикла в случае, если «-1» никогда не становится истинным?

Answer 1

Один из них будет в бесконечном цикле, увеличивая температуру чьего-то устройства и тратит процессорные циклы!

Это неправда, и я думаю, что большая часть того, почему вы задаете этот вопрос. read() делает не busy wait (т. Е. Запрашивать процессор постоянно), если ему нечего читать. Поэтому на практике не было бы серьезной проблемы, если -1 не возвращается.

read() также выбрасывает IOException в случае, если что-то не так с чтением (например, если InputStream закрыт). Убедившись у вас есть есть цикл внутри примерки блока вместе с проверкой на -1, более чем достаточно для убедившись, что он будет выходить из цикла, как таковой:

try { 
    int b; 
    while ((b=inputStream.read() > -1) 
    { 
     //Do something 
    } 
} catch (IOException e) { 
    e.printStackTrace(); 
} 

Answer 2

что, если», просто говоря: «что, если» соединение закрыто, но read() не возвращается »-1

Нет такого состояния. Это противоречие в терминах.

Что делать, если что-то происходит, а -1 никогда не становится истинным?

Не может.

Один из них будет в бесконечном цикле, увеличивая температуру чьего-либо устройства и теряя процессорные циклы!

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

Как можно быть уверенным?

Вы можете поверить в спецификацию и не задавать себе противоречивые вопросы.

NB Тестирование для сокета или входного потока, являющегося нулевым после, вы пытались прочитать и не имели исключения, или EOS бесполезен.