The JDK definition of the Serializable interface is:
Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.
The vernacular expression is: the serializability of classes is enabled by implementing the Serializable interface earlier, and classes that do not implement this interface cannot be serialized and deserialized. At the same time, when a class becomes serializable, all its subclasses will also be serializable. The Serializable interface has no methods, no property definitions, and is just a serializable identity interface.
It seems to be very simple, but this serialization of JAVA itself is very involved, and the doorway inside is not necessarily less than those tall serialization families.
1. Can a class be serialized, and what are the requirements? Let's start with the basics,
1) First of all, as mentioned above, you must implement the Serializable interface, which is the first step, which can be understood as a switch. Next, to the definition of the class itself, we usually define a class, there must be some properties in it, and these properties have their own types. So if we need this class to be serialized normally, the properties in the class cannot be defined arbitrarily, such as the following example
static class Vo1 implements Serializable { private int num; private String name; private Integer use; private FieldX fieldX; public Vo1(int num, String name, Integer use, FieldX fieldX) { this.num = num; this.name = name; this.use = use; this.fieldX = fieldX; } public Vo1(int num, String name, Integer use) { this.num = num; this.name = name; this.use = use; } @Override public String toString() { return new StringJoiner(", ", Vo1.class.getSimpleName() + "[", "]").add("num=" + num).add("name='" + name + "'").add("use=" + use).add("fieldX=" + fieldX).toString(); } }static class FieldX{ private String name; private String value; public FieldX(String name, String value) { this.name = name; this.value = value; } @Override public String toString() { return new StringJoiner(", ", FieldX.class.getSimpleName() + "[", "]").add("name='" + name + "'").add("value='" + value + "'").toString(); } } @Test void testSer() throws Exception{ Vo1 vo1 = new Vo1(123,"Test",100); Vo1 vo2 = new Vo1(123,"Test",100,new FieldX("F1","V1")); System.out.println("vo1"); try(ObjectOutputStream serializable=new ObjectOutputStream(new FileOutputStream("G://vo1.txt"))) { serializable.writeObject(vo1); } System.out.println("vo2"); try(ObjectOutputStream serializable=new ObjectOutputStream(new FileOutputStream("G://vo2.txt"))) { serializable.writeObject(vo2); } } , vo1 instances can be serialized normally, while vo2 instances cannot be serialized normally, indicating that the FieldX type is not serializable.
2) So to ensure that a class can be serialized normally, on the basis of implementing the Serializable interface, you must also ensure that all the properties in this class that need to be serialized meet the serializable conditions, and the FieldX class also needs to implement the interface Serializable, and so on. So what if there are properties that don't need to be serialized? We'll add this later.
3) All properties in the class do not contain class properties, that is, the static variables in the class are not within the above range, because of the essence of serialization. II. What is the purpose of class serialization? To put it simply: the object instances generated by our program itself during the running process are themselves stored in the JVM, which means that they only exist in memory, which means that these in-memory object instances will theoretically be released and recycled when the program terminates. So, if we have some scenarios that need to be accessed and used after the program runs, and even the object instances generated in one program can be accessed and used in another program, how to meet these application scenarios? The answer is serialization.
Serialization has two main purposes:
1 is the persistence of the state of the object instance, which is stored on the hard disk or other media that can be stored persistently, so as to ensure that it will not disappear with the memory release when the program terminates, and can be persisted.
2 is the sharing of object instances, and the serialized object instances can be sent and propagated through media such as the network, and can be accessed and used in other programs.
III. Advantages and disadvantages of JDK serialization.
AT PRESENT, THERE ARE MANY EXCELLENT SERIALIZATION SUPPORT IN THE JAVA FIELD, AND THE SERIALIZATION OF THE JDK ITSELF HAS ALSO BEEN CRITICIZED A LOT, AND ITS PERFORMANCE DOES NOT HAVE ADVANTAGES. In my opinion, its main advantages may be generality and simplicity, so JDK serialization remains active on some performance-insensitive nodes (less demanding). If you are in some performance-sensitive nodes, you may need to refer to some more advantageous protocols, such as: Protobuf, JSON and other serialization methods.
This issue aims to briefly introduce the basics of JDK serialization, and the next issue continues to talk about "The Pit in JDK Serialization!".
