Introduction
Imagine you want to save the state of one or more objects. For example an Object User you'd have to use one of the I/O classes to write out the state of the instance variables of all the objects you want to save. The worst part would be trying to reconstruct new objects that were virtually identical to the objects you were trying to save. You'd need your own protocol for the way in which you wrote and restored the state of each object, or you could end up setting variables with the wrong values. For example, imagine you stored an object that has instance variables for login and password. At the time you save the state of the object, you could write out the height and weight as two String object in a file, but the order in which you write them is crucial.
Maybe, you‘d use for example an Object JSON (external lib) to write your object in list of key/value and restore your object manually or automatically by I/O.
It would be all too easy to re-create the object but mix up the login and password values—using the saved password as the value for the new object's login and vice versa.
Serialization lets you simply say "save this object and all of its instance variables."
Actually it is a little more interesting than that, because you can add, "... unless I've explicitly marked a variable as transient, which means, don't include the transient variable's value as part of the object's serialized state."
As we know Object and instances variable lives always in heap. Local variable live in stack l and they will be cleaned when method finish to run. Once you've declared and initialized a variable, a natural question is "How long will this variable be around?" This is a question regarding the scope of variables.
For the purposes of discussing the scope of variables, we can say that there are four basic scopes:
· Static variables have the longest scope; they are created when the class is loaded, and they survive as long as the class stays loaded in the Java Virtual Machine (JVM).
· Instance variables are the next most long-lived; they are created when a new instance is created, and they live until the instance is removed.
· Local variables are next; they live as long as their method remains on the stack. As we'll soon see, however, local variables can be alive, and still be "out of scope".
· Block variables live only as long as the code block is executing
As we see in the preview scope, any object will live after application exit in JVM. And my first question is: “how persist object to exist beyond the lifetime of the JMV and to restore at any time” this is the main purpose of the processing called “Serialization”.
Serialization
Serialization is the process of converting a set of object instance that contain references to each other into a linear stream of bytes, which can then be sent through a socket, stored to a file, or simply manipulated as a stream of data, as well as the process of rebuilding those bytes into a live object at some future time. So when is serialization used? Serialization is used when you want to persist the object. It is also used by RMI to pass objects between JVMs, either as arguments in a method invocation from a client to a server or as return values from a method invocation. In general, serialization is used when we want the object to exist beyond the lifetime of the JVM.
The most obvious is that you can transmit the serialized class over a network, and the recipient can construct a duplicate of the original instance. Likewise, you can save a serialized structure to a file system. Also, note that serialization is recursive, so you can serialize an entire heterogeneous data structure in one time
Serialization is very used in input/ output operation in Java. Here they are several reasons:
· Communication: If you have two machines that are running the same code, and they need to communicate, an easy way is for one machine to build an object with information that it would like to transmit, and then serialize that object to the other machine. It's not the best method for communication, but it gets the job done.
· Persistence: If you want to store the state of a particular operation in a database, it can be easily serialized to a byte array, and stored in the database for later retrieval.
· Deep Copy: If you need an exact replica of an Object, and don't want to go to the trouble of writing your own specialized clone() class, simply serializing the object to a byte array, and then de-serializing it to another object achieves this goal.
· Caching: Really just an application of the above, but sometimes an object takes 10 minutes to build, but would only take 10 seconds to de-serialize. So, rather than hold onto the giant object in memory, just cache it out to a file via serialization, and read it in later when it's needed.
· Cross JVM Synchronization: Serialization works across different JVMs that may be running on different architectures.
In addition of this precedent reason, here is other:
· To send data to a remote computer using such client/server Java technologies as RMI or socket programming.
· To "flatten" an object into array of bytes in memory.
· To exchange data between applets and servlets.
· To store user session in Web applications.
· To activate/passivation enterprise java beans.
· To send objects between the servers in a cluste
· When you want to send something money or other thing, you should assemble, marshal all and wrap it (Serialization) and send, save or stock it, depending what you want. After if you or receiver want retrieve the pieces, you have to unwrap (Deserialization)
· Banking example: When the account holder tries to withdraw money from the server through ATM, the account holder information along with the withdraw details will be serialized (marshalled/flattened to bytes) and sent to server where the details are deserialized (rebuilt the bytes) and used to perform operations. This will reduce the network calls as we are serializing the whole object and sending to server and further request for information from client is not needed by the server.
· Stock example: Let’s say a user wants the stock updates immediately when he request for it. To achieve this, every time we have an update, we can serialize it and save it in a file. When user requests the information, deserialized it from file and provide the information. This way we don’t need to make the user wait for the information until we hit the database, perform computations and get the result.
So far we saw what and when serialization used, in the following paragraph, we will see Serialization in Java Context. How Java perform Serialization.
