The role of the serial number

The role of the serial number: serialVersionUID

 

1, network transmission, persistence,

2. When deserializing, if there is no version number and the original entity class has changed, the deserialization used at this time will throw an exception. With the version flag, there will be no exception, and the new one will be automatically assigned a default value.

 

 

 

 

Java serialization encodes an object into a byte stream, and deserialization converts the byte stream encoding into an object. Serialization is a method of implementing persistent storage in Java; it provides a wire-level object representation for data transmission.

Java's serialization mechanism verifies version consistency by judging the serialVersionUID of the class at runtime. When deserializing, the JVM will compare the serialVersionUID in the incoming byte stream with the serialVersionUID of the local corresponding entity (class). Exceptions with inconsistent versions. 

The serializable class XXXXXX does not declare a static final serialVersionUID field of type long in Eclipse displays such a warning. 
When using the program's Add default Serial version ID to repair, Eclipse will add: private static final long serialVersionUID = 1L; 
when using the program's Add generated Serial version ID to repair, Eclipse will add: private static final long serialVersionUID = xxxxL; 

In fact, the specific reason for this problem is related to the serialVersionUID in serialization. serialVersionUID is used to indicate compatibility between different versions of the class. There are two generation methods: one is the default 1L; the other is to generate a 64-bit hash field according to the class name, interface name, member method and attribute, etc.
In the JDK, you can use the serialver.exe tool in the bin directory of the JDK to generate the value of the serialVersionUID. For Test.class, execute the command: 

serialver Test At this time, the JVM (java virtual machine) will generate a hash field. 

Compare the value of this hash field with the field value generated in method 2. It can be seen that the use of the serialver command in CMD is based on the class name, interface name, member method and attribute to generate the hash field. 

Why do you need to overload the serialVersionUID property in the java class. 
When two processes are communicating remotely, various types of data can be sent to each other. Regardless of the type of data, it is transmitted over the network as a binary sequence. The sender needs to convert the Java object into a sequence of bytes before it can be sent over the network; the receiver needs to restore the sequence of bytes to a Java object. The process of converting a Java object to a byte sequence is called object serialization, and the process of restoring a byte sequence to a Java object is called object deserialization. 

  Serialization of objects has two main purposes: 
  1) Permanently save the byte sequence of the object to the hard disk, usually in a file; 
  2) Transmit the byte sequence of the object on the network. 
java.io.ObjectOutputStream represents the object output stream, and its writeObject(Object obj) method can serialize the obj object specified by the parameter, and write the obtained byte sequence to a target output stream. java.io.ObjectInputStream represents an object input stream, and its readObject() method reads byte sequences from a source input stream, deserializes them into an object, and returns it. Only objects of classes that implement the Serializable or Externalizable interface can be serialized. The Externalizable interface inherits from the Serializable interface. The class that implements the Externalizable interface completely controls the serialization behavior by itself, while the class that only implements the Serializable interface can use the default serialization method. All classes that implement the Serializable interface have a static variable representing the serialized version identifier: private static final long serialVersionUID; The default value of the serialVersionUID of the class depends entirely on the implementation of the Java compiler. For the same class, use different Java compilers Compiler may result in a different serialVersionUID. Explicitly defining serialVersionUID has two purposes: 

  1) In some cases, you want different versions of a class to be serializable compatible, so you need to ensure that different versions of a class have the same serialVersionUID; in some cases, you don't want different versions of a class Compatible with serialization, so you need to ensure that different versions of the class have different serialVersionUIDs. 

  2) When you serialize a class instance and want to change a field or add a field without setting serialVersionUID, any changes made will cause the old instance to fail to deserialize and throw a abnormal. If you add serialVersionUID, when deserializing old instances, newly added or changed field values ​​will be set to initialized values ​​(null for objects, corresponding initial default values ​​for primitive types), and fields deleted will not be set. 

The serialization algorithm generally follows the steps:

  1. Output class metadata related to object instances.
  2. Recursively output the superclass description of the class until there are no more superclasses.
  3. After the class metadata is complete, start to output the actual data value of the object instance from the top-level superclass.
  4. Recursively output the data of the instance from top to bottom
 

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326344746&siteId=291194637