Quando DataInputStream.skipBytes(n) non può saltare n byte?

Question

IL Documentazione Sun per DataInput.skipBytes afferma che "tenta di saltare n byte di dati dal flusso di input, scartando i byte saltati.Tuttavia, potrebbe saltare un numero minore di byte, possibilmente zero.Ciò può derivare da una serie di condizioni;raggiungere la fine del file prima che siano stati saltati n byte è solo una possibilità."

1. Oltre a raggiungere la fine del file, perché potrebbe skipBytes() non saltare il giusto numero di byte?(IL DataInputStream Sto usando will wrap a FileInputStream o a PipedInputStream.)

2. Se voglio assolutamente saltare n byte e lanciare un file EOFException se questo mi fa andare alla fine del file, dovrei usare readFully() e ignorare l'array di byte risultante?O c'è un modo migliore?

Answer 1

1) Potrebbero non esserci molti dati disponibili da leggere (l'altra estremità della pipe potrebbe non aver ancora inviato così tanti dati) e la classe di implementazione potrebbe non essere bloccante (cioèrestituirà semplicemente ciò che può, invece di attendere dati sufficienti per soddisfare la richiesta).

Non so, tuttavia, se qualche implementazione si comporti effettivamente in questo modo, ma l'interfaccia è progettata per consentirlo.

Un'altra opzione è semplicemente che il file venga chiuso durante la lettura.

2) ReadFully() (che attenderà sempre input sufficienti altrimenti fallirà) o chiamerà skipBytes() in un ciclo.Penso che il primo sia probabilmente migliore, a meno che la gamma non sia veramente vasta.

Answer 2

Mi sono imbattuto in questo problema oggi.Stava leggendo una connessione di rete su una macchina virtuale, quindi immagino che potrebbero esserci diverse ragioni per cui ciò accade.L'ho risolto semplicemente forzando il flusso di input a saltare i byte finché non ha saltato il numero di byte che volevo:

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 pubblicizzato di recente.È coerente nel senso che non è garantito che InputStream.read legga quanti più byte potrebbe.Tuttavia, è assolutamente inutile come metodo API.Probabilmente anche InputStream dovrebbe avere readFully.

Answer 4

Si scopre che readFully() aggiunge un sovraccarico di prestazioni maggiore di quanto fossi disposto a sopportare.

Alla fine ho raggiunto un compromesso:Chiamo skipBytes() una volta e, se restituisce un numero di byte inferiore al numero corretto, chiamo readFully() per i byte rimanenti.