Когда DataInputStream.skipBytes (n) не может пропустить n байтов?

Question

Документация Sun для DataInput.skipBytes гласит, что он "делает попытку пропустить n байтов данных из входного потока, отбрасывая пропущенные байты. Однако он может пропустить некоторое меньшее количество байт, возможно, ноль. Это может быть следствием любого из ряда условий; достижение конца файла до того, как n байтов было пропущено, является единственной возможностью. "

1. Кроме достижения конца файла, почему бы skipBytes() не пропустить нужное количество байтов? (DataInputStream, который я использую, будет либо обернуть FileInputStream, либо PipedInputStream.)

2. Если я определенно хочу пропустить n байтов и выбросить EOFException, если это заставит меня перейти к концу файла, следует ли мне использовать readFully() и игнорировать полученный байтовый массив? Или есть лучший способ?

Answer 1

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

Однако я не знаю, ведут ли себя какие-либо реализации таким образом, но интерфейс разработан для этого.

Другой вариант заключается в том, что файл закрывается на полпути через чтение.

2) Либо readFully () (который всегда будет ждать достаточного количества ввода, либо произойдет сбой), либо вызовите skipBytes () в цикле. Я думаю, что первое, вероятно, лучше, если массив не является действительно обширным.

Answer 2

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

int byteOffsetX = someNumber; //n bytes to skip
int nSkipped = 0;

nSkipped = in.skipBytes(byteOffsetX);
while (nSkipped < byteOffsetX) {
    nSkipped = nSkipped + in.skipBytes(byteOffsetX - nSkipped);
}

Answer 3

Оказывается, что readFully () добавляет больше производительности, чем я готов был смириться.

В конце концов я скомпрометировал: я вызываю skipBytes () один раз, и если он возвращает меньше правильного числа байтов, я вызываю readFully () для оставшихся байтов.

Answer 4

Джош Блох недавно опубликовал это. Это согласуется с тем, что InputStream.read не гарантирует чтение столько байтов, сколько мог Тем не менее, это совершенно бессмысленно как метод API. InputStream, вероятно, также должен иметь readFully.