What does InputStream.available () do in Java?

What does InputStream.available() in Java? I read the documentation, but I still can't figure it out.

Doc says:

Returns the number of bytes that can be read (or skipped) from this input stream without blocking by the next caller for this input stream. The next caller may be the same thread or another thread.

The available method for the InputStream class always returns 0.

What do they mean by blocking? Does it just mean a synchronous call?

And, first of all, what is the purpose of the available() method?

+41
java inputstream blocking
Sep 12 '10 at 15:27
source share
4 answers

The lock here is not related to threads or synchronization. Instead, it refers to IO blocking (see this for more information). If you issue a read request and the channel is unavailable, the blocking call will wait (or block) until data is available (or the channel is closed, throws an exception, etc.).

So why use available() ? This way you can determine the number of bytes to read or determine if you are going to block.

Please note that Java also has non-blocking I / O capabilities. See here for more details.

+24
Sep 12 '10 at 15:34
source share

In InputStreams, read() calls are called blocking method calls. This means that if there is no data during a method call, the method will wait for data to be received.

The available() method tells you how many bytes can be read until the read() call blocks the execution flow of your program. In most input streams, all read() calls are blocked, so the available one returns 0 by default.

However, in some streams (such as BufferedInputStream , which have an internal buffer), some bytes are read and stored in memory, so you can read them without blocking the program stream. In this case, the available() method tells you how many bytes are stored in the buffer.

+30
Sep 12 '10 at 15:30
source share

Consider if you write VERY BAD .. and you write the operating system.

This operating system also uses a keyboard.

So, you ask your OS to go and get some input from the keyboard, but no keys are pressed, and there are no keys in the buffer. your whole OS will HAGE DEAD until it receives keyboard input.

Compare this to looking ahead, you ask if the KB has any characters before making a call. You get a NO answer, so your OS then goes and does something else.

That's why you should take care, now if you then multiply this with all the other potentially blocking tasks, you can understand why looking ahead is crucial.

Because this also applies to OUTPUT: memory on the drive interface can also drop data on the drive faster than it can handle. if you do not know that the drive buffer is flooded with data, then the task will be blocked until the buffer can receive more data.

It also emphasizes the nonsense of "very few useful uses."

-2
Sep 15 '13 at 4:10
source share

One possible practical use of available() use it to select a reasonable buffer length.

 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; } 

The document says:

Returns: an estimate of the number of bytes that can be read (or skipped) from this input stream without blocking, or 0 when it reaches the end of the input stream .

and

An implementation of this subclass may throw an IOException if this input stream has been closed by calling the close() method.

UPDATE

I already know that the idea is not recommended. I knew the risk was even before the JDK document warned. (I once tried to allocate a buffer from available size of several GB FileInputStream .)

JDK8 / InputStream available #

It is incorrect to use the return value of this method to allocate a buffer designed to store all data in this stream.

JDK5 / InputStream # availabe

But when programming, there should never be code never or always wrong . This is what I believe in.

-2
Jan 25 '16 at 9:34
source share



All Articles