A talk on Java Learning (IV.)

1. About serialization and deserialization

We should all probably know the meaning of serialization and deserialization in Java, serialization is the conversion of a Java object into binary to transmit on disk or network stream, and deserialization means to reassemble the received binary stream into the original object inversion process. They are implemented in Java, respectively, through the two classes of ObjectInputStream and ObjectInputStream (hereinafter referred to as OIS and Oos respectively).

The WriteObject () method of the Oos is used to perform the process of serialization, Ois ReadObject () is used to perform deserialization, and before the binary stream is transmitted, the two high-level stream objects need to be connected to the same channel, which can be disk files , or it can be a socket-bottom stream. So either way, the underlying stream objects are passed in the form of constructor parameters into the Oos and ois of the two high-level streams, the connection is completed before binary data transmission can be made. Example:

Can be a file stream channel

File = new file ("C:/data.dat");

Oos = new ObjectOutputStream (new FileOutputStream (file));

OIS = new ObjectInputStream (new FileInputStream (file));

or network streaming channel

Oos = new ObjectOutputStream (Socket.getoutputstream ());

OIS = new ObjectInputStream (Socket.getinputstream ());

I wonder if you have noticed that Oos is always defined before ois, and I do not want you to misunderstand whether the order is fixed or not. The answer is no, so is there a sequential requirement? The answer is yes. What is the principle?

The principle is that the interface between the input/output stream must be an output stream first initialized and then input stream initialization, otherwise it will throw an exception. People will certainly ask why? Just a little look at the source code files of these two classes probably know that the output stream task is very simple, as long as the object into the binary into the channel to write it, but the input stream needs to do a lot of preparation to accept and eventually reorganize the object, So ObjectInputStream's constructor needs to use header information sent over output initialization, this method is called Readstreamheader (), It will read two short values to determine how much caching is used to store the binary stream sent over by the channel, which is not the same size as the JRE version. So if output is not initialized first, the constructor of input will not run correctly first.

For the above two examples, the first order is strict, the second because the Oos and OIS connection is not the other side, but the other end of the socket flow, need to be in strict accordance with the other side of the output stream before the docking input stream open to run smoothly.

This writeobject and readobject are inherently thread-safe and are not allowed to be accessed concurrently during transmission. So the object can be a succession of passing over, there are many people in the run will encounter Eofexception, and then baffled, go to various forums to ask the solution. In fact, I would like to say that this exception is not required to declare, that is, although it is abnormal, but is actually the end of the normal operation of the flag. EOF indicates that the end of the file is read and the natural connection is disconnected when the send ends. If this affects the correctness of your program, please calm down and look at the business logic of your program, rather than focusing narrowly on sending and receiving methods. Because the author is also plagued by such a bug 1 day, by many forum posts misunderstood a lot of the last learned lessons. If you go to ReadObject in the while loop, there is no problem in nature, there is object data to read, no automatic blocking. Then throw eofexception must be because the connection is broken and continue to read, what causes the connection broken? Must be the business logic where there are errors, such as Nullpoint, Classcaseexception, Arrayoutofbound, even if the program is larger, it doesn't matter, at most a single pace can quickly find bugs and solve it.

No wonder a program Master said: Solve the problem 90% by experience, 5% by technology, leaving 5% by luck! It is a very good idea, the author probably consulted over 30 discussions in the while loop using ReadObject to throw Eofexceptionde posts, we all blindly focus on the interpretation of this noun, deserialization behavior or against such writing, and no one thinks that EOF is the right behavior, It's actually very honest in doing it thing. Why is it that everyone ignores the place where it really went wrong? Two words, experience!