Blazkowiczметод InputStream.available() бесполезен и даже сломан для сокетов.
Он всегда был бесполезен для клиентского кода. Из разумных его применений я вижу только его использование в различных Buffered* обертках. Там обертка может увидеть, что данных много, и реалоцировать буфер.

BlazkowiczЧитаем JavaDoc
Returns:an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking or 0 when it reaches the end of the input stream.

На сокетах available будет изначально возвращать 0, если узел с другой стороны ничего не отправляет. Но это ещё не значит что поток завершен.

Вы javadoc неправильно понимаете. Javadoc и не обещает, что 0 - это только конец потока. У вас возвращается "number of bytes that can be read without blocking". Ну нет там байтов, чтобы читать. И ноль - вполне корректное значение для первой половины (даже когда конец потока еще не достигнут). Причем "0 в случае конце файла" - это всего лишь уточнение. Оно вполне следует из первой половины контракта. По той же самой причине - "из потока можно прочитать не более 0 байт без блокирования". Разница с read есть, но для данного места оно вполне оправдана. Файловые потоки тоже могут возвращать 0 раньше достижения конца файла.

BlazkowiczWTF#2 Дальше хуже. read(), который должен вернуть -1 по окончании чтения тоже никогда -1 не возвращает. В общем случае никакого начала и конца у InputStream для сокетов нет. А использовать available для хоть какой-то эмуляции неблокируемости тоже не выйдет.

Начало есть. Если сделать Socket.shutdownOutput на стороне клиента, то у сервера и конец потока будет. А если не делать, то и конца не будет. Что логично - по одному соединению можно обмениваться многими соединениями. И даже тот же браузер может не закрывать сокет (поэтому -1 и не будет), а использовать его для послдеюущих запросов.

BlazkowiczНачал тестировать на боевом приложении, WTF#3
Клиент отправляет пакет данных. Он прочитан, перенаправлен на другой сервер. После этого мой серверный сокет снова пытается сделать read(). В теории он должен либо заблокироваться, либо вернуть -1.
На практике чтение выкидывает исключение Connection reset! Но это пол беды. Помимо этого клиентская сторона закрывает свой сокет и на запись. Т.е. отклик сервера записать проигнорировав reset уже нельзя.

Код смотреть надо. Вы там никакой из сокетных потоков или оберток над ними вручную не закрываете? Закрытие любого из них будет приводить к закрытию сокета. Или на сервере вместо shutdown сокету делается close. Для надежной доставки данных нельзя "просто закрыть потоки и сокет". Сначала нужно сделать shutdown (один или два, в зависимости от того, что делаете). И только потом закрывать сокет. В случае исключений shutdown делать уже не имеет смысла.

BlazkowiczWTF#4 - не смотря на connection reset и невозможность дальнейшей работы с клиентом со стороны сервера, никакие флаги у сокета не меняются. Всякие connected, closed и пр. находятся в том же состоянии что и в начале работы. Т.е. спросит клиента с сервера живо ли тот ещё никакой возможности не видно.

Это плохая документация. "isConnected" вооще обозначает, что "соединение хоть когда-то было установлено (смотрите документацию)", а не "сейчас соединение установлено". При использовании большей части конструкторов isConnected всегда будет true. С isClosed ситуация чем-то похожая. Этот флаг всего лишь обозначает, что "сокет был закрыт вызовом метода close или закрытием одного из сокетных потоков". Он не обозначает, что клиент на другой стороне закрыл соединение и т.п. Да, завершение соединения с другой стороны/ошибки/сброс соединения сокет не закрывают. Его все равно нужно закрыть вручную.

BlazkowiczWTF#5 - я вообще смотрю на разные проекты и вижу что постоянные исключения в TCP на Java это вообще штатные ситуации. Имеет ли смысл избегать логирования stacktrace для повышения производительности? Ведь если разворачивать stacktrace на каждый пук при многочисленых соединениях и отсоединениях клиентов, то провал в производительности обеспечен.

Да, достаточно штатная. Логировать ли - зависит от приложения и нагрузки. Во многих случаях протокол имеет явные начало/конец (с соответствующими shutdown и т.п.), поэтому исключения при допустимой нагрузке логировать стоит (мало ли что там). А вот если вы какой-нибудь streaming server пишете, где клиент в какой-то момент просто исчезает (приложение закрыли), там можно и не логировать ничего.

В спойлере пример. Проверял на www.apache.org порт 80. Никаких исключений. Никаких проблем с сокетами. Радостно общается с браузером потоков в 10 и при этом с HTTP keep-alive (видно по логам и сообщениям о закрытии сокетов). Соединения могут закрываться и при неактивности (т.е. конец файла определяется с обеих сторон), тоже видно по сообщениям.

Если делать совсем правильно, читалку и писалку тоже нужно разделить на два потока (на три потока, в примере две записи). Читалка складывает данные в буфер. Если данных в буфере слишком много, закрывает сокет со второй стороны и свой сокет (генерируя попутно кучу исключений в духе SocketClosedException, ConnectionReset и т.п.).