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

In this issue, the editor will bring you about the use of serialVersionUID. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Serialization is a means of object persistence. It is widely used in network transmission, RMI and other scenarios. Class enables its serialization capabilities by implementing the java.io.Serializable interface.

However, there is one knowledge point that has not been introduced, and that is about serialVersionUID. What exactly is the use of this field? What happens if you don't set it up?

Background knowledge

First, let's briefly introduce some knowledge related to serialization.

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.

How does it ensure that only methods that implement this interface can be serialized and deserialized?

Reason:

When serializing, it determines whether the class to be serialized is of type Enum, Array, and Serializable, and throws a NotSerializableException directly if it is not.

The Externalizable interface is also provided in Java, which can also be implemented to provide serialization capabilities.

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

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.

Custom serialization policy

During serialization, if the writeObject and readObject methods are defined in the serialized class, the virtual machine attempts to call the writeObject and readObject methods in the object class for user-defined serialization and deserialization.

If there is no such method, the default calls are the defaultWriteObject method of ObjectOutputStream and the defaultReadObject method of ObjectInputStream.

User-defined writeObject and readObject methods allow users to control the serialization process, such as dynamically changing the serialization value during the serialization process.

Therefore, when you need to define a serialization policy for some special fields, you can consider using transient decoration and overriding the writeObject and readObject methods yourself, as in java.util.ArrayList.

These are the things that some readers need to know about serialization.

If we randomly find a few classes in Java that implement serialization interfaces, such as String, Integer, etc., we can find a detail, that is, these classes not only implement Serializable, but also define a serialVersionUID.

So, what exactly is serialVersionUID? Why set such a field?

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.

What happens if serialVersionUID changes?

Let's give an example of what happens if serialVersionUID is modified.

Write a User1 object to a file. Then we modify the User1 class to change the value of serialVersionUID to 2L.

Then execute the code to deserialize the objects in the file:

The implementation results are as follows:

Java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2

You can see that the above code throws a java.io.InvalidClassException and points out that the serialVersionUID is inconsistent.

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.

In a compatibility upgrade, do not change the reason for serialVersionUID when modifying a class. Unless the two versions are completely incompatible. So, serialVersionUID actually verifies version consistency.

If the reader is interested, you can take out all versions of the JDK code and take a look at the serialVersionUID of those backward compatible classes that have not changed. For example, the serialVersionUID of the String class is always-6849794470754667710L.

However, the editor believes that this standard can actually be more stringent, that is, the regulation:

If a class implements the Serializable interface, you must manually add a private static final long serialVersionUID variable and set the initial value.

Why should a serialVersionUID be clearly identified?

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.

The above is the use of the serialVersionUID that the editor shared for you. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.