¿Cuándo puede DataInputStream.skipBytes(n) no omitir n bytes?

Question

El Documentación de Sun para DataInput.skipBytes afirma que "intenta omitir n bytes de datos del flujo de entrada, descartando los bytes omitidos.Sin embargo, puede omitir un número menor de bytes, posiblemente cero.Esto puede resultar de una serie de condiciones;llegar al final del archivo antes de que se hayan omitido n bytes es sólo una posibilidad."

1. Aparte de llegar al final del archivo, ¿por qué podría skipBytes() ¿No te saltas el número correcto de bytes?(El DataInputStream que estoy usando estará envolviendo un FileInputStream o un PipedInputStream.)

2. Si definitivamente quiero omitir n bytes y lanzar un EOFException Si esto hace que vaya al final del archivo, ¿debería usar? readFully() e ignorar la matriz de bytes resultante?¿O hay un mejor camino?

Answer 1

1) Es posible que no haya tantos datos disponibles para leer (es posible que el otro extremo de la tubería no haya enviado tantos datos todavía) y que la clase de implementación no sea bloqueante (es decir,simplemente devolverá lo que pueda, en lugar de esperar a que haya suficientes datos para cumplir con la solicitud).

Sin embargo, no sé si alguna implementación realmente se comporta de esta manera, pero la interfaz está diseñada para permitirlo.

Otra opción es simplemente que el archivo se cierre a mitad de la lectura.

2) Ya sea readFully() (que siempre esperará suficiente entrada o fallará) o llamará a skipBytes() en un bucle.Creo que lo primero es probablemente mejor, a menos que la variedad sea realmente amplia.

Answer 2

Me encontré con este problema hoy.Estaba leyendo una conexión de red en una máquina virtual, así que imagino que podría haber varias razones para que esto suceda.Lo resolví simplemente forzando el flujo de entrada a omitir bytes hasta que omitió la cantidad de bytes que quería:

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

Josh Bloch lo ha hecho público recientemente.Es coherente en el sentido de que no se garantiza que InputStream.read lea tantos bytes como podría.Sin embargo, es completamente inútil como método API.Probablemente InputStream también debería tener readFully.

Answer 4

Resulta que readFully() agrega más sobrecarga de rendimiento de la que estaba dispuesto a soportar.

Al final me comprometí:Llamo a skipBytes() una vez, y si eso devuelve menos del número correcto de bytes, llamo a readFully() para los bytes restantes.