高赞学习博客:https://juejin.cn/post/6844903848167866375#heading-6
2.实现方式
- 序列化: 将对象写入到 IO 流中。
- 反序列化: 将对象从 IO 流中恢复。
- 意义: 序列化机制允许将实现了序列化接口的 Java 对象转换成字节序列,这些字节序列可以保存在磁盘中,或通过网络传输,以达到以后恢复成原来的java对象。序列化机制使得对象可以脱离程序的运行而独立存在。
- 使用场景:所有可在网络上传输的对象都必须是可序列化的,比如RMI(remote method invoke,即远程方法调用),传入的参数或返回的对象都是可序列化的,否则会出错;所有需要保存到磁盘的java 对象都必须是可序列化的。通常建议:程序创建的每个JavaBean 类都实现 Serializeable 接口。
Java 中实现序列化的两种方式:继承 Serializable/ Externalizable
2.1、继承 Serializable接口: 序列化:public class Dog implements Serializable { private String name; public Dog(String name) { this.name = name; } @Override public String toString() { return "Dog{" + "name='" + name + ''' + '}'; } }
Test结果:
@Test public void testSerializable(){ try { //1.//创建一个ObjectOutputStream输出流 ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("serializable.txt")); //2.将对象序列化到文件中 Dog dog = new Dog("柯基"); out.writeObject(dog); } catch (IOException e) { e.printStackTrace(); } }反序列化:
注意 :实现了Serializable 反序列化并不会调用构造方法。反序列的对象是由JVM自己生成的对象,不通过构造方法生成?。(而 Externalizable 则不同)。
在 Dog 的构造方法中添加日志,反序列化的时候未打印。
public Dog() { System.out.println("Dog 无参构造器"); } public Dog(String name) { System.out.println("Dog 有参构造器"); this.name = name; }
Test结果:
同一对象序列化多次,会将这个对象序列化多次吗?答案是否定的。
注意:
2.2、继承 Externalizable 接口
- 反序列化的顺序与序列化时的顺序一致。
- 从结果可以看出:Java序列化同一对象,并不会将此对象序列化多次得到多个对象。
- 如果一个可序列化的类的成员不是基本类型,也不是String类型,那这个引用类型也必须是可序列化的;否则,会导致此类不能序列化。
Externalizable接口不同于Serializable接口,实现此接口必须实现接口中的两个方法实现自定义序列化,这是强制性的;特别之处是必须提供pulic的无参构造器,因为在反序列化的时候需要反射创建对象。
public class Cat implements Externalizable { private String name; private int age; //注意,必须加上pulic 无参构造器 // public Cat() { // System.out.println("Cat 无参构造器"); // } public Cat(String name, int age) { System.out.println("Cat 有参构造器"); this.name = name; this.age = age; } @Override public void writeExternal(ObjectOutput out) throws IOException { out.writeUTF(name); out.writeInt(age); } @Override public void readExternal(ObjectInput in) throws ClassNotFoundException, IOException { name = in.readUTF(); age = in.readInt(); } @Override public String toString() { return "Cat{" + "name='" + name + ''' + ", age=" + age + '}'; } }
注意: 未加默认无参构造器,在反序列化的时候会报错,而 实现了 Serializable 接口则可以。
为 Cat 添加无参构造器后。
-
所有保存到磁盘的对象都有一个序列化编码号
-
当程序试图序列化一个对象时,会先检查此对象是否已经序列化过,只有此对象从未(在此虚拟机)被序列化过,才会将此对象序列化为字节序列输出。
-
如果此对象已经序列化过,则直接输出编号即可。
由于java序利化算法不会重复序列化同一个对象,只会记录已序列化对象的编号。如果序列化一个可变对象(对象内的内容可更改)后,更改了对象内容,再次序列化,并不会再次将此对象转换为字节序列,而只是保存序列化编号。
验证的时候如博客出现的情况:
5、两者比较使用 transient 关键字可以选择不需要序列化的字段。使用transient修饰的属性,java序列化时,会忽略掉此字段,所以反序列化出的对象,被transient修饰的属性是默认值。对于引用类型,值是null;基本类型,值是0;boolean类型,值是false。
通过重写 writeOject与readObject方法,可以自己选择哪些属性需要序列化, 哪些属性不需要。如果writeObject使用某种规则序列化,则相应的readObject需要相反的规则反序列化,以便能正确反序列化出对象。
6、序列化版本号 serialVersionUID虽然Externalizable接口带来了一定的性能提升,但变成复杂度也提高了,所以一般通过实现Serializable接口进行序列化。
我们知道,反序列化必须拥有class文件,但随着项目的升级,class文件也会升级,序列化怎么保证升级前后的兼容性呢?
java序列化提供了一个private static final long serialVersionUID的序列化版本号,只有版本号相同,即使更改了序列化属性,对象也可以正确被反序列化回来。
public class Person implements Serializable { //序列化版本号 private static final long serialVersionUID = 1111013L; private String name; private int age; //省略构造方法及get,set }
如果反序列化使用的class的版本号与序列化时使用的不一致,反序列化会报InvalidClassException异常。
序列化版本号可自由指定,如果不指定,JVM会根据类信息自己计算一个版本号,这样随着class的升级,就无法正确反序列化;不指定版本号另一个明显隐患是,不利于jvm间的移植,可能class文件没有更改,但不同jvm可能计算的规则不一样,这样也会导致无法反序列化。
什么情况下需要修改serialVersionUID呢?分三种情况。
- 如果只是修改了方法,反序列化不容影响,则无需修改版本号;
- 如果只是修改了静态变量,瞬态变量(transient修饰的变量),反序列化不受影响,无需修改版本号;
- 如果修改了非瞬态变量,则可能导致反序列化失败。**如果新类中实例变量的类型与序列化时类的类型不一致,则会反序列化失败,这时候需要更改serialVersionUID。**如果只是新增了实例变量,则反序列化回来新增的是默认值;如果减少了实例变量,反序列化时会忽略掉减少的实例变量。
8、安卓中的序列化
- 所有需要网络传输的对象都需要实现序列化接口,通过建议所有的javaBean都实现Serializable接口。
- 对象的类名、实例变量(包括基本类型,数组,对其他对象的引用)都会被序列化;方法、类变量、transient实例变量都不会被序列化。
- 如果想让某个变量不被序列化,使用transient修饰。
- 序列化对象的引用类型成员变量,也必须是可序列化的,否则,会报错。
- 反序列化时必须有序列化对象的class文件。
- 当通过文件、网络来读取序列化后的对象时,必须按照实际写入的顺序读取。
- 单例类序列化,需要重写readResolve()方法;否则会破坏单例原则。
- 同一对象序列化多次,只有第一次序列化为二进制流,以后都只是保存序列化编号,不会重复序列化。 见前面的示例
- 建议所有可序列化的类加上serialVersionUID 版本号,方便项目升级。
Parcelable的性能比Serializable好,在内存开销方面较小,所以在内存间数据传输时推荐使用Parcelable
public class User implements Parcelable { public int id; public String name; public User friend; protected User(Parcel in) { this.id = in.readInt(); this.name = in.readString(); //friend是另一个序列化对象,此方法序列需要传递当前线程的上下文类加载器,否则会报无法找到类的错误 this.friend = in.readParcelable(Thread.currentThread().getContextClassLoader()); } public static final CreatorCREATOR = new Creator () { @Override public User createFromParcel(Parcel in) { return new User(in); } @Override public User[] newArray(int size) { return new User[size]; } }; @Override public int describeContents() { return 0; } //将对象写入到序列化结构中 @Override public void writeToParcel(Parcel dest, int flags) { dest.writeInt(id); dest.writeString(name); dest.writeParcelable(this.friend,0); } }
Parcelable 与 Serializable 区别【重点】 (1)两者的实现差异通过writeToParcel将我们的对象映射成Parcel对象,再通过createFromParcel将Parcel对象映射成我们的对象。也可以将Parcel看成是一个类似Serliazable的读写流,通过writeToParcel把对象写到流里面,在通过createFromParcel从流里读取对象,这个过程需要我们自己来实现并且写的顺序和读的顺序必须一致。
(2)两者的设计初衷Serializable的实现,只需要实现Serializable接口即可。这只是给对象打了一个标记(UID),系统会自动将其序列化。而Parcelabel的实现,不仅需要实现Parcelabel接口,还需要在类中添加一个静态成员变量CREATOR,这个变量需要实现 Parcelable.Creator 接口,并实现读写的抽象方法。
(3)两者效率选择Serializable的设计初衷是为了序列化对象到本地文件、数据库、网络流、RMI以便数据传输,当然这种传输可以是程序内的也可以是两个程序间的。而Android的Parcelable的设计初衷是由于Serializable效率过低,消耗大,而android中数据传递主要是在内存环境中(内存属于android中的稀有资源),因此Parcelable的出现为了满足数据在内存中低开销而且高效地传递问题。
- Serializable使用IO读写存储在硬盘上。序列化过程使用了反射技术,并且期间产生临时对象,优点代码少,在将对象序列化到存储设置中或将对象序列化后通过网络传输时建议选择Serializable。
- Parcelable是直接在内存中读写,我们知道内存的读写速度肯定优于硬盘读写速度,所以Parcelable序列化方式性能上要优于Serializable方式很多。所以Android应用程序在内存间数据传输时推荐使用Parcelable,如activity间传输数据和AIDL数据传递。大多数情况下使用Serializable也是没什么问题的,但是针对Android应用程序在内存间数据传输还是建议大家使用Parcelable方式实现序列化,毕竟性能好很多,其实也没多麻烦。
- Parcelable也不是不可以在网络中传输,只不过实现和 *** 作过程过于麻烦并且为了防止android版本不同而导致Parcelable可能不同的情况,因此在序列化到存储设备或者网络传输方面还是尽量选择Serializable接口。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)