Shulou(Shulou.com)06/02 Report--

This article shares with you the content of the sample analysis of serialVersionUID in JAVA serial numbers. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Specification of serialVersionUID

Serializable and Externalizable

The Java class enables its serialization capabilities by implementing the java.io.Serializable interface. Classes that do not implement this interface cannot be serialized or deserialized. All subtypes of a serializable class are themselves serializable.

If you look at the source code of Serializable, you will find that it is just an empty interface with nothing in it. The Serializable interface has no methods or fields and is only used to identify serializable semantics. However, if a class does not implement this interface and wants to be serialized, a java.io.NotSerializableException exception is thrown.

When the sequence number is written as a binary stream, the following method is called:

Externalizable inherits from Serializable, which defines two abstract methods: writeExternal () and readExternal ().

Developers need to override the writeExternal () and readExternal () methods when using the Externalizable interface for serialization and deserialization. Otherwise, the values of all variables will become default values.

Transient does not need to be serialized

The function of the transient keyword is to control the serialization of the variable. Adding this keyword before the variable declaration can prevent the variable from being serialized into the file. After being deserialized, the value of the transient variable is set to the initial value, such as 0 for int and null for the object.

What is serialVersionUID?

Serialization is the process of converting the state information of an object into a form that can be stored or transmitted. We all know that the Java object is stored in JVM's heap memory, that is, if the JVM heap no longer exists, the object disappears.

Serialization provides a solution that allows you to save objects even if JVM is down. Just like the flash drive we usually use. Serialize Java objects into a form (such as a binary stream) that can be stored or transferred, such as in a file. In this way, when the object is needed again, the binary stream is read from the file and the object is deserialized from the binary stream.

Whether the virtual machine allows deserialization depends not only on whether the classpath and functional code are consistent, but also on whether the serialization ID of the two classes is the same. This so-called serialization ID is the serialVersionUID that we define in the code.

This is because, when deserializing, JVM compares the serialVersionUID in the incoming byte stream with the serialVersionUID of the corresponding local entity class. If the same is considered to be consistent, it can be deserialized, otherwise there will be an exception of inconsistent serialization version, that is, InvalidCastException.

Why the default serialVersionUID value must be set

Let's see what happens if we don't explicitly define a serialVersionUID in the class.

Try to modify the demo code above, first define an object with the following class, which does not define serialVersionUID, and write it to the file.

Then we modify the User1 class to add an attribute to it. Trying to read it out of the file and deserialize it.

Execution result:

Java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID =-298778152837257883, local class serialVersionUID = 7961728318907695402

Similarly, an InvalidClassException is thrown and points out that the two serialVersionUID are different, namely-2986778152837257883 and 7961728318907695402.

As you can see here, the system itself has added a serialVersionUID.

Therefore, once the class implements Serializable, it is recommended that you explicitly define a serialVersionUID. Otherwise, an exception will occur when you modify the class.

SerialVersionUID can be generated in two ways:

One is the default 1L, such as:

Private static final long serialVersionUID = 1L

The other is to generate a 64-bit hash field based on class name, interface name, member methods and properties, such as:

Private static final long serialVersionUID = xxxxL

The latter can be generated with the help of IDE, which will be described later.

The principle behind

To simplify the amount of code, the call chain for deserialization is as follows:

In initNonProxy, the key code is as follows:

During deserialization, the serialVersionUID is compared, and if it is found that it is not equal, an exception is thrown directly.

Take a closer look at the getSerialVersionUID method:

When no serialVersionUID is defined, the computeDefaultSUID method is called to generate a default serialVersionUID.

This leads to the root cause of the above two problems, which is actually a strict check in the code and an serialVersionUID is automatically generated when it is not defined.

IDEA hint

To ensure that we do not forget to define serialVersionUID, we can adjust the configuration of Intellij IDEA. After implementing the Serializable interface, if serialVersionUID is not defined, IDEA (like eclipse) will prompt:

And you can generate one with one click:

Of course, this configuration does not take effect by default. You need to manually set it in IDEA:

At the place labeled 3 in the figure (Serializable class without serialVersionUID configuration), check and save.

Thank you for reading! This is the end of this article on "sample Analysis of serialVersionUID in JAVA Serial numbers". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.