java如何在objectinputstream中的readObject知道要读取多少字节？

Question

In socket I/O, may I know how does a objectinputstream readObject knows how many bytes to read? Is the content length encapsulated inside the bytes itself or does it simply reads all the available bytes in the buffer itself?

I am asking this because I was referring to the Python socket how-to and it says

Now if you think about that a bit, you'll come to realize a fundamental truth of sockets: messages must either be fixed length (yuck), or be delimited (shrug), or indicate how long they are (much better), or end by shutting down the connection. The choice is entirely yours, (but some ways are righter than others).

However in another SO answer , @DavidCrawshaw mentioned that `

So readObject() does not know how much data it will read, so it does not know how many objects are available.

I am interested to know how it works...

Answer 1

You're over-interpreting the answer you cited. readObject() doesn't know how many bytes it will read, ahead of time, but once it starts reading it is just parsing an input stream according to a protocol, that consists of tags, primitive values, and objects, which in turn consist of tags, primitive values, and other objects. It doesn't have to know ahead of time. Consider the similar-ish case of XML. You don't know how long the document will be ahead of time, or each element, but you know when you've read it all, because the protocol tells you.

Answer 2

The readOject() method is using BlockedInputStream to read the byte.If you check the readObject of ObjectInputStream , it is calling

readObject0(false).

private Object readObject0(boolean unshared) throws IOException {
    boolean oldMode = bin.getBlockDataMode();
    if (oldMode) {
        int remain = bin.currentBlockRemaining();
        if (remain > 0) {
        throw new OptionalDataException(remain);
        } else if (defaultDataEnd) {
        /*
         * Fix for 4360508: stream is currently at the end of a field
         * value block written via default serialization; since there
         * is no terminating TC_ENDBLOCKDATA tag, simulate
         * end-of-custom-data behavior explicitly.
         */
        throw new OptionalDataException(true);
        }
        bin.setBlockDataMode(false);
    }

    byte tc;
    while ((tc = bin.peekByte()) == TC_RESET) {
        bin.readByte();
        handleReset();
    }

which is reading from the stream is using bin.readByte(). bin is BlockiedDataInputStream which in turns use PeekInputStream to read it.This class finally is using InputStream.read(). From the description of the read method:

/**
     * 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.

So basically it reads byte after byte until it encounters -1.So As EJP mentioned, it never know ahead of time how many bytes are there to be read. Hope this will help you in understanfing it.