First of all, people familiar with Java may know, Java is not repeated in the Inputstream read.
But there is no thought, InputStream read why can not repeat it?
In fact, to answer the "why" question is very simple, the interface is so designed that people can not repeat read.
So the question to be discussed today is more like: Why Java's InputStream can not be designed to duplicate read?
Why can not repeat on InputStream read online also have to say:
Some students said:
"InputStream on the analogy into a cup, like a glass of water in the InputStream data, you put the glass of water out, and there is no cup of water, InputStream is the same reason."
Very good analogy, let us know why not repeat the InputStream be read intuitively.
And some students from a deeper point of view to analyze the code:
"When InputStream read, there will be a pos pointer, he indicated that the starting position after each read next to be read, when read when the last character, pos pointer does not reset."
He said also makes sense, that InputStream read is one-way. But not all are like this InputStream implementation class implementation.

// BufferedInputStream snippet:
 public synchronized int read() throws IOException {
        if (pos >= count) {
            fill();
            if (pos >= count)
                return -1;
        }
        return getBufIfOpen()[pos++] & 0xff;
    }

// FileInputStream snippet:
public native int read() throws IOException;

we know:
Internal List Java is to use an array to achieve, it also has to traverse a pos pointer. But he did not say List traverse a second pass is not. The second pass is to create a new Iterator, so pos returned to the array starting position. For some InputStream can certainly do the same. For example: ByteArrayInputStream
ByteArrayInputStream is to save a Java byte array to the object, and then traverse the time to read the byte array.

public ByteArrayInputStream(byte buf[]) {
        this.buf = buf;
        this.pos = 0;
        this.count = buf.length;
}

public synchronized int read() {
        return (pos < count) ? (buf[pos++] & 0xff) : -1;
}

ByteArrayInputStream on terms to achieve repeatable read is very simple, but why not. I would like to follow a unified standard of InputStream.
Clearly stated in the comments read method of InputStream:

/**
     * Reads the next byte of data from the input stream. The value byte is
     * returned as an <code>int</code> in the range <code>0</code> to
     * <code>255</code>. If no byte is available because the end of the stream
     * has been reached, the value <code>-1</code> is returned. This method
     * blocks until input data is available, the end of the stream is detected,
     * or an exception is thrown.
     *
     * <p> A subclass must provide an implementation of this method.
     *
     * @return     the next byte of data, or <code>-1</code> if the end of the
     *             stream is reached.
     * @exception  IOException  if an I/O error occurs.
     */
    public abstract int read() throws IOException;

When the stream reaches the end, it returns -1.

In fact, such as FileInputStream file stream to achieve reuse may not be difficult, what's the use of the cache should be able to do (read large files on the tragedy, Ha ha ha).
But InputStream name suggests is a one-way stream of bytes, with the same water, in order to use it again to go to the source of their own to take it.
In fact, unlike InputStream cup, more like a pipe, to drink plenty of water, and the water in the cup holder between the water and let the water into the cup (Note: this action after the completion of the water inside the water would not ).
It would appear, InputStream is actually a data channel, is only responsible for the flow of data, and other areas of work are not responsible for data processing and storage.
Recall that, in fact, some InputStream implementation class can implement processing data. But did not do so, it is the importance of norms and standards.