本文探讨了Java RMI（Remote Method Invocation）机制中的序列化过程，解释了远程服务器发送时如何通过代理（stub）进行通信，以及serialVersionUID在序列化检测中的作用。通过实例展示了如何实现序列化效率的提升，并讨论了Serializable与Externalizable接口的使用。
1.About Stub:
java.rmi.server.RemoteStub is a class that implements the Serializable interface. The RMI serialization mechanism knows that whenever a remote server is "sent" over the wire, the server object should be replaced by a stub that knows how to communicate with the server (e.g.,a stub that knows on which machine and port the server is listening).Calling Naming.rebind( ) actually winds up passing a stub to the RMI registry.
When clients make calls to Naming.lookup( ), as in the following code snippet, they also receive copies of the stub. Since the stub is serializable, there's no problem in making a copy of it.
2. About serialVersionUID:
serialVersionUID: serialization detects Class Change.
serialVersionUID doesn't have to be private. However, it must be static, final, and long.
Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don't set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value.
An important point is that you can decide whether to implement Externalizable or Serializable on a class-by-class basis. Within the same application, some of your classes can be Serializable, and some can be Externalizable. This makes it easy to evolve your application in response to actual performance data and shifting requirements. The following two-part strategy is often quite nice:
· Make all your classes implement Serializable.
· After that, make some of them, the ones you send often and for which serialization is dramatically inefficient, implement Externalizable instead.
This gets you most of the convenience of serialization and lets you use Externalizable to optimize when appropriate.
Experience has shown that, over time, more and more objects will gradually come to directly extend Object and implement Externalizable. But that's fine. It simply means that the code was incrementally improved in response to performance problems when the application was deployed.
Note: Serialization mechanism is deep copy, so, the class will be serialized should be as 'thin' as possible.
java.rmi.server.RemoteStub is a class that implements the Serializable interface. The RMI serialization mechanism knows that whenever a remote server is "sent" over the wire, the server object should be replaced by a stub that knows how to communicate with the server (e.g.,a stub that knows on which machine and port the server is listening).Calling Naming.rebind( ) actually winds up passing a stub to the RMI registry.
When clients make calls to Naming.lookup( ), as in the following code snippet, they also receive copies of the stub. Since the stub is serializable, there's no problem in making a copy of it.
2. About serialVersionUID:
serialVersionUID: serialization detects Class Change.
serialVersionUID doesn't have to be private. However, it must be static, final, and long.
Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don't set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value.
An important point is that you can decide whether to implement Externalizable or Serializable on a class-by-class basis. Within the same application, some of your classes can be Serializable, and some can be Externalizable. This makes it easy to evolve your application in response to actual performance data and shifting requirements. The following two-part strategy is often quite nice:
· Make all your classes implement Serializable.
· After that, make some of them, the ones you send often and for which serialization is dramatically inefficient, implement Externalizable instead.
This gets you most of the convenience of serialization and lets you use Externalizable to optimize when appropriate.
Experience has shown that, over time, more and more objects will gradually come to directly extend Object and implement Externalizable. But that's fine. It simply means that the code was incrementally improved in response to performance problems when the application was deployed.
Note: Serialization mechanism is deep copy, so, the class will be serialized should be as 'thin' as possible.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
