Note that in the implementation of InputStream, this method always
return 0. It is intended for BufferedInputStream to return the
remaining bytes in the buffer.

you might decide it is not worth your while doing a read, you have
other fish to fry. You will come back later and try again when there
is a big enough batch worth the overhead of a read to the OS.

Not very important.  You probably wouldn't want to use it.  If you don't
understand well exactly what it does (and doesn't) do and when and why
you might want that, then save yourself grief and pretend that the
method doesn't exist.  It is rarely used by people who do know and
understand all that.

It means that the next read on the input stream will retrieve at least
that number of bytes, provided that that number or more are requested.
Furthermore, the read will not block if the number of bytes returned by
available() is greater than zero.  Note, however, that by the time the
read is actually performed, there may be more bytes available, so a
return value of zero doesn't necessarily mean that the next read will
block.  Note also that available() will, perforce, return zero when the
end of the stream has been detected, and that a read on the stream will
not block in that case, either.  A common mistake is to assume that
available() returning zero is a definite signal of end-of-stream; that
assumption is false.

Contrary to ozgwei's comments, available is for more than just
BufferedInputStream, but he is right about how BufferedInputStream
implements the method.  Note that java.io.InputStream itself is abstract.

It tells you the number of bytes in the current input buffer, as opposed to
the total number of bytes waiting in the stream itself.

It means that available() tells you how many bytes are available for reading
without requiring the machine go to the network connection to fetch more
data. IOW, it's the number of bytes already available in the buffer.