Java serialization (2)

Java serialization (2)
Next, the previous article said that when any class inherits the Serializable interface, Eclipse often prompts a yellow exclamation point. The message is as follows: the serializable class Person does not declare a static final serialVersionUID field of type long. After The parameter is set to long, the system selects Adds a default serial version ID to The selected type. use this option to add a user-defined ID in combination with custom serialization code if the type did undergo structural changes since its first release. another one is Adds a generated serial version ID to the selected type. use thi S option to add a compiler-generated ID if the type did not undergo structural changes since its first release. So what is the serialVersionUID? To put it simply, you can explain this/***/private static final long serialVersionUID = 1L. Eclipse helps us to explain this statement. In fact, the main application scenario of java serialization is rmi. Remote interface call. Let me give you an example. The process of her serialization and deserialization is separated into two projects (note that although there are two projects, the packages should be the same). After running, the program will be normal, however, note that if the serialVersionUID value of the person class of your two projects is different at this time. You will find that the deserialization fails. Serialization and deserialization are successful only when the value is equal. In fact, this value is mainly used to force the client to update the interface. (Often used in RMI) For example, the client has A class A and the server has A Class. At this time, two ends use rmi for communication. Assume that Class A of the server modifies some content, such as adding or deleting A field. How do you notify the client at this time, you can modify the value of serialVersionUID to be different from that of the client. In this way, errors will occur during serialization or deserialization. As a result, the client will know that the serialization error will update the interface. In addition, the previous article also showed that the default call to the serialization process is the defaultWriteObject method of ObjectOutputStream and the defaultReadObject method of ObjectInputStream. Of course, we can also manually write the method to call it, the writeObject and readObject methods allow users to control the serialization process. In addition to better controlling the events consumed by serialization, manual control also provides encryption, for example, if we want to serialize a user's user name and password, you may be crawled by default. However, if you manually serialize the user name and password, it is very secure to decrypt the data during deserialization. Let's look at another piece of code. Copy code 1 package com. burning. test; 2 3 import java. io. serializable; 4 5 public class Person implements Serializable {6 7 public static final int STATIC_VALUE = 100; 8 9 10 @ Override11 public String toString () {12 return "Person [name =" + name + ", age =" + age + "]"; 13} 14 15 public String getName () {16 return name; 17} 18 19 public void setName (String name) {20 this. name = name; 21} 22 23 public int g EtAge () {24 return age; 25} 26 27 public void setAge (int age) {28 this. age = age; 29} 30 31 private String name; 32 33 private int age; 34 35} copy the code and check the main copy code 1 package com. burning. test; 2 3 import java. io. file; 4 import java. io. fileInputStream; 5 import java. io. fileNotFoundException; 6 import java. io. fileOutputStream; 7 import java. io. IOException; 8 import java. io. objectInputStream; 9 import java. I O. objectOutputStream; 10 11 public class TestMain {12 13 public static void main (String [] args) {14 // TODO Auto-generated method stub15 File file = new File ("person2.out"); 16 ObjectInputStream oin = null; 17 ObjectOutputStream oout = null; 18 try {19 oout = new ObjectOutputStream (new FileOutputStream (file); 20 Person person = new Person (); 21 oout. writeObject (person); 22 oout. flush (); 23 24 System. out. Println ("1st times after writing" + file. length (); 25 oout. writeObject (person); 26 System. out. println ("2nd times after writing" + file. length (); 27 oout. close (); 28 oin = new ObjectInputStream (new FileInputStream (file); 29 Object obj = oin. readObject (); 30 Object obj2 = oin. readObject (); 31 System. out. println (obj = obj2); 32 33} catch (FileNotFoundException e) {34 // TODO Auto-generated catch block35 e. printStackTrace (); 36} catch (IOException e) {37 // TODO Auto-generated catch block38 e. printStackTrace (); 39} catch (ClassNotFoundException e) {40 // TODO Auto-generated catch block41 e. printStackTrace (); 42} finally {43 try {44 oout. close (); 45} catch (IOException e) {46 // TODO Auto-generated catch block47 e. printStackTrace (); 48} 49 try {50 oin. close (); 51} catch (IOException e) {52 // TODO Auto-generated catch block53 e. p RintStackTrace (); 54} 55 56} 57 58} 59} copy the code and run the program. The result is 88 true after 1st and 2nd. The running results are clear at a glance. We found that the Java serialization mechanism has specific storage rules to save disk space. When the file to be written is the same object, the object content will not be stored, but a reference will be stored again. The 5-byte storage space added above is the space for adding references and some control information. During deserialization, the reference relationship is restored so that t1 and t2 in listing 3 point to a unique object. The two are equal and the output is true. This storage rule greatly saves storage space. Then let's modify the main class copy code package com. burning. test; import java. io. file; import java. io. fileInputStream; import java. io. fileNotFoundException; import java. io. fileOutputStream; import java. io. IOException; import java. io. objectInputStream; import java. io. objectOutputStream; public class TestMain {public static void main (String [] args) {// TODO Auto-generated method stub File file = new File ("person2.out"); Object InputStream oin = null; ObjectOutputStream oout = null; try {oout = new ObjectOutputStream (new FileOutputStream (file); Person person = new Person (); person. setAge (10); oout. writeObject (person); oout. flush (); System. out. println ("1st times after writing" + file. length (); person. setAge (20); oout. writeObject (person); System. out. println ("2nd times after writing" + file. length (); oout. close (); oin = new ObjectInputStream (new FileI NputStream (file); Object obj = oin. readObject (); Object obj2 = oin. readObject (); System. out. println (obj. toString (); System. out. println (obj2.toString ();} catch (FileNotFoundException e) {// TODO Auto-generated catch block e. printStackTrace ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace ();} catch (ClassNotFoundException e) {// TODO Auto-generated catch block E. printStackTrace ();} finally {try {oout. close ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace ();} try {oin. close ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace () ;}}} copy the code and check the running result. After writing the result for 1st times, 83 times and 2nd times, 88 Person [name = null, age = 10] Person [name = null, age = 10] we will find that the result is like this, because after the object is saved for the first time, although you have modified the value of this object, but when you serialize the object for the second time, the two objects will not reference the same Change the value. Only some references are saved, so a strange result is obtained ~ Next, let's take a good look at modifying main again to check the running result and copy the code package com. burning. test; import java. io. file; import java. io. fileInputStream; import java. io. fileNotFoundException; import java. io. fileOutputStream; import java. io. IOException; import java. io. objectInputStream; import java. io. objectOutputStream; public class TestMain {public static void main (String [] args) {// TODO Auto-generated method stub File file = new File ("person4. Out "); ObjectInputStream oin = null; ObjectOutputStream oout = null; try {oout = new ObjectOutputStream (new FileOutputStream (file); Person person = new Person (); person. setAge (10); oout. writeObject (person); oout. flush (); System. out. println ("1st times after writing" + file. length (); Person person2 = new Person (); person2.setAge (20); oout. writeObject (person2); System. out. println ("2nd times after writing" + file. length (); oout. Close (); oin = new ObjectInputStream (new FileInputStream (file); Object obj = oin. readObject (); Object obj2 = oin. readObject (); System. out. println (obj. toString (); System. out. println (obj2.toString ();} catch (FileNotFoundException e) {// TODO Auto-generated catch block e. printStackTrace ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace ();} catch (ClassNotFoundEx Ception e) {// TODO Auto-generated catch block e. printStackTrace ();} finally {try {oout. close ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace ();} try {oin. close ();} catch (IOException e) {// TODO Auto-generated catch block e. printStackTrace () ;}}} the result of copying the code is 94 persons [name = null, age = 10] Person [name = null, age = 20] It should be better understood after reading this result.