Che cosa fa InputStream.available() in Java?

Question

Cosa fa InputStream.available() in Java? Ho letto la documentazione, ma non riesco ancora a capirlo.

Il dottore dice:

Restituisce il numero di byte che possono essere letti (o saltato) da questo flusso di input senza bloccare dalla prossima chiamante di un metodo per questo flusso di input. Il prossimo chiamante potrebbe essere lo stesso thread o un altro thread.

Il metodo disponibile per la classe InputStream restituisce sempre 0.

cosa si intende per bloccando? Significa solo una chiamata sincronizzata?

E soprattutto, qual è lo scopo del metodo available()?

Answer 1

Il blocco non riguarda la filettatura o la sincronizzazione qui. Invece si riferisce al blocco dell'IO (vedi this per maggiori informazioni). Se si invia una richiesta di lettura e il canale non ne ha, una chiamata di blocco attenderà (o bloccherà) finché i dati non saranno disponibili (o il canale è chiuso, genera un'eccezione ecc.)

Quindi perché utilizzare available()? In questo modo puoi determinare quanti byte leggere o determinare se stai per bloccare.

Si noti che Java ha anche capacità di IO non bloccanti. Vedere here per ulteriori dettagli

Answer 2

In InputStreams, le chiamate read() sono chiamate di metodo "bloccanti". Ciò significa che se non ci sono dati disponibili al momento della chiamata al metodo, il metodo attenderà che i dati siano resi disponibili.

Il metodo available() indica quanti byte possono essere letti fino a quando la chiamata read() bloccherà il flusso di esecuzione del programma. Sulla maggior parte dei flussi di input, tutte le chiamate a read() stanno bloccando, ecco perché disponibile restituisce 0 per impostazione predefinita.

Tuttavia, su alcuni flussi (ad esempio BufferedInputStream, che dispongono di un buffer interno), alcuni byte vengono letti e conservati in memoria, quindi è possibile leggerli senza bloccare il flusso del programma. In questo caso, il metodo available() indica quanti byte sono conservati nel buffer.

Answer 3

Considerare se si scrive software MOLTO CATTIVO .. e si scrive un sistema operativo.

Questo sistema operativo accetta l'input da tastiera, tra le altre cose.

Così chiedete al sistema operativo di andare e ottenere un input da tastiera, ma non ci sono tasti premuti e nessuno nel buffer. l'intero sistema operativo HANG DEAD finché non riceve un input da tastiera.

Contrasto con "guarda avanti", chiedi se il KB ha caratteri PRIMA di effettuare la chiamata. Si ottiene la risposta NO, quindi il sistema operativo va e fa qualcos'altro.

Questo è PERCHÉ dovresti preoccuparti, ora se poi lo moltiplichi per ogni altro compito potenzialmente bloccante, puoi capire perché 'guardare avanti' è fondamentale.

Perché si applica anche a OUTPUT: una memoria su un'interfaccia dell'unità disco può anche inondare i dati sull'unità disco più rapidamente di quanto non possa elaborarli. se non si sa che il buffer dell'unità è inondato di dati, l'attività bloccherà fino a quando il buffer non potrà accettare più dati.

Ciò evidenzia anche il non senso di "ci sono pochissimi usi utili".

Answer 4

Uno dei possibilmente pratico utilizza available() per scegliere una lunghezza del buffer ragionevole.

static final int LEN = 4096; 

long copy(InputStream in, OutputStream out) throws IOException { 
    int count = 0L; 
    int avl = in.available(); 
    if (avl == 0) { 
     // 0 returned without IOException? possibly mean eof? 
     return 0L; 
    } 
    //byte[] buf = new byte[avl == 0 ? LEN : Math.min(avl, LEN)]; 
    byte[] buf = new byte[Math.min(avl, LEN)]; 
    for (int len; (len = in.read(buf)) != -1; count+= len) { 
     out.write(buf, 0, len); 
    } 
    return count; 
} 

Il documento dice,

Reso: una stima del numero di byte che possono essere letti (o saltati) da questo flusso di input senza bloccare o 0 quando raggiunge la fine del flusso di input.

E

Una sottoclasse implementazione di questo metodo può scegliere di lanciare un IOException se questo flusso di input è stato chiuso richiamando il metodo close().

UPDATE

so già l'idea non è raccomandato. Ho conosciuto questo rischio anche prima che il documento di JDK lo avvertisse. (Una volta ho provato a allocato un buffer dalla available di qualche GB dimensioni FileInputStream.)

JDK8/InputStream#available

Non è mai corretto usare il valore di ritorno di questo metodo per allocare un buffer destinato a contenere tutti i dati in questo flusso.

JDK5/InputStream#availabe

Ma, nella programmazione, non ci dovrebbero nessun codice never o always wrong. Questo è quello che sto credendo.