共计 6266 个字符,预计需要花费 16 分钟才能阅读完成。
工具人
曾几何时,对于 Java 的序列化的认知始终停留在:「实现个 Serializbale
接口」不就好了的状态,直到 …
所以这次抽时间再次从新捧起了尘封已久的《Java 编程思维》,就像之前梳理《枚举局部常识》一样,把「序列化和反序列化」这块的知识点又从新扫视了一遍。
序列化是干啥用的?
序列化的本来用意是心愿对一个 Java 对象作一下“变换”,变成字节序列,这样一来不便长久化存储到磁盘,防止程序运行完结后对象就从内存里隐没,另外变换成字节序列也更便于网络运输和流传,所以概念上很好了解:
- 序列化:把 Java 对象转换为字节序列。
- 反序列化:把字节序列复原为原先的 Java 对象。
而且序列化机制从某种意义上来说也补救了平台化的一些差别,毕竟转换后的字节流能够在其余平台上进行反序列化来复原对象。
事件就是那么个事件,看起来很简略,不过前面的货色还不少,请往下看。
对象如何序列化?
然而 Java 目前并没有一个关键字能够间接去定义一个所谓的“可长久化”对象。
对象的长久化和反长久化须要靠程序员在代码里手动 显式地 进行序列化和反序列化还原的动作。
举个例子,如果咱们要对 Student
类对象序列化到一个名为 student.txt
的文本文件中,而后再通过文本文件反序列化成 Student
类对象:
1、Student 类定义
public class Student implements Serializable {
private String name;
private Integer age;
private Integer score;
@Override
public String toString() {
return "Student:" + 'n' +
"name =" + this.name + 'n' +
"age =" + this.age + 'n' +
"score =" + this.score + 'n'
;
}
// ... 其余省略 ...
}
2、序列化
public static void serialize( ) throws IOException {Student student = new Student();
student.setName("CodeSheep");
student.setAge(18);
student.setScore(1000);
ObjectOutputStream objectOutputStream =
new ObjectOutputStream(new FileOutputStream( new File("student.txt") ) );
objectOutputStream.writeObject(student);
objectOutputStream.close();
System.out.println("序列化胜利!曾经生成 student.txt 文件");
System.out.println("==============================================");
}
3、反序列化
public static void deserialize( ) throws IOException, ClassNotFoundException {
ObjectInputStream objectInputStream =
new ObjectInputStream(new FileInputStream( new File("student.txt") ) );
Student student = (Student) objectInputStream.readObject();
objectInputStream.close();
System.out.println("反序列化后果为:");
System.out.println(student);
}
4、运行后果
控制台打印:
序列化胜利!曾经生成 student.txt 文件
==============================================
反序列化后果为:Student:
name = CodeSheep
age = 18
score = 1000
Serializable 接口有何用?
下面在定义 Student
类时,实现了一个 Serializable
接口,然而当咱们点进 Serializable
接口外部查看,发现它 居然是一个空接口,并没有蕴含任何办法!
试想,如果下面在定义 Student
类时忘了加 implements Serializable
时会产生什么呢?
试验后果是:此时的程序运行 会报错 ,并抛出NotSerializableException
异样:
咱们依照谬误提醒,由源码始终跟到 ObjectOutputStream
的writeObject0()
办法底层一看,才豁然开朗:
如果一个对象既不是 字符串 、 数组 、 枚举 ,而且也没有实现Serializable
接口的话,在序列化时就会抛出 NotSerializableException
异样!
哦,我明确了!
原来 Serializable
接口也仅仅只是做一个标记用!!!
它通知代码只有是实现了 Serializable
接口的类都是能够被序列化的!然而真正的序列化动作不须要靠它实现。
serialVersionUID
号有何用?
置信你肯定常常看到有些类中定义了如下代码行,即定义了一个名为 serialVersionUID
的字段:
private static final long serialVersionUID = -4392658638228508589L;
你晓得这句申明的含意吗?为什么要搞一个名为 serialVersionUID
的序列号?
持续来做一个简略试验,还拿下面的 Student
类为例,咱们并没有人为在外面显式地申明一个 serialVersionUID
字段。
咱们首先还是调用下面的 serialize()
办法,将一个 Student
对象序列化到本地磁盘上的 student.txt
文件:
public static void serialize() throws IOException {Student student = new Student();
student.setName("CodeSheep");
student.setAge(18);
student.setScore(100);
ObjectOutputStream objectOutputStream =
new ObjectOutputStream(new FileOutputStream( new File("student.txt") ) );
objectOutputStream.writeObject(student);
objectOutputStream.close();}
接下来咱们在 Student
类外面动点手脚,比方在外面再减少一个名为 studentID
的字段,示意学生学号:
这时候,咱们拿方才曾经序列化到本地的 student.txt
文件,还用如下代码进行反序列化,试图还原出方才那个 Student
对象:
public static void deserialize( ) throws IOException, ClassNotFoundException {
ObjectInputStream objectInputStream =
new ObjectInputStream(new FileInputStream( new File("student.txt") ) );
Student student = (Student) objectInputStream.readObject();
objectInputStream.close();
System.out.println("反序列化后果为:");
System.out.println(student);
}
运行发现 报错了 ,并且抛出了InvalidClassException
异样:
这中央提醒的信息十分明确了:序列化前后的 serialVersionUID
号码不兼容!
从这中央最起码能够得出 两个 重要信息:
- 1、serialVersionUID 是序列化前后的惟一标识符
- 2、默认如果没有人为显式定义过
serialVersionUID
,那编译器会为它主动申明一个!
第 1 个问题: serialVersionUID
序列化 ID,能够看成是序列化和反序列化过程中的“暗号”,在反序列化时,JVM 会把字节流中的序列号 ID 和被序列化类中的序列号 ID 做比对,只有两者统一,能力从新反序列化,否则就会报异样来终止反序列化的过程。
第 2 个问题: 如果在定义一个可序列化的类时,没有人为显式地给它定义一个 serialVersionUID
的话,则 Java 运行时环境会依据该类的各方面信息主动地为它生成一个默认的 serialVersionUID
,一旦像下面一样更改了类的构造或者信息,则类的serialVersionUID
也会跟着变动!
所以,为了 serialVersionUID
的确定性,写代码时还是倡议,但凡 implements Serializable
的类,都最好人为显式地为它申明一个 serialVersionUID
明确值!
当然,如果不想手动赋值,你也能够借助 IDE 的主动增加性能,比方我应用的 IntelliJ IDEA
,按alt + enter
就能够为类主动生成和增加 serialVersionUID
字段,非常不便:
两种非凡状况
- 1、但凡被
static
润饰的字段是不会被序列化的 - 2、但凡被
transient
修饰符润饰的字段也是不会被序列化的
对于第一点 ,因为序列化保留的是 对象的状态 而非类的状态,所以会疏忽 static
动态域也是理所应当的。
对于第二点 ,就须要理解一下transient
修饰符的作用了。
如果在序列化某个类的对象时,就是不心愿某个字段被序列化(比方这个字段寄存的是隐衷值,如:明码
等),那这时就能够用 transient
修饰符来润饰该字段。
比方在之前定义的 Student
类中,退出一个 明码字段 ,然而不心愿序列化到txt
文本,则能够:
这样在序列化 Student
类对象时,password
字段会设置为默认值null
,这一点能够从反序列化所失去的后果来看出:
序列化的受控和增强
约束性加持
从下面的过程能够看出,序列化和反序列化的过程其实是 有破绽的,因为从序列化到反序列化是有两头过程的,如果被他人拿到了两头字节流,而后加以伪造或者篡改,那反序列化进去的对象就会有肯定危险了。
毕竟反序列化也相当于一种 “隐式的”对象结构 ,因而咱们心愿在反序列化时,进行 受控的 对象反序列化动作。
那怎么个受控法呢?
答案就是: 自行编写 readObject()
函数,用于对象的反序列化结构,从而提供约束性。
既然自行编写 readObject()
函数,那就能够做很多可控的事件:比方各种判断工作。
还以下面的 Student
类为例,一般来说学生的问题应该在 0 ~ 100
之间,咱们为了避免学生的考试成绩在反序列化时被他人篡改成一个奇葩值,咱们能够自行编写 readObject()
函数用于反序列化的管制:
private void readObject(ObjectInputStream objectInputStream) throws IOException, ClassNotFoundException {
// 调用默认的反序列化函数
objectInputStream.defaultReadObject();
// 手工查看反序列化后学生问题的有效性,若发现有问题,即终止操作!if(0 > score || 100 < score) {throw new IllegalArgumentException("学生分数只能在 0 到 100 之间!");
}
}
比方我成心将学生的分数改为101
,此时反序列化立马终止并且报错:
对于下面的代码,有些小伙伴可能会好奇,为什么自定义的 private
的readObject()
办法能够被主动调用,这就须要你跟一下底层源码来一探到底了,我帮你跟到了 ObjectStreamClass
类的最底层,看到这里我置信你肯定豁然开朗:
又是反射机制在起作用!是的,在 Java 里,果然万物皆可“反射”(滑稽),即便是类中定义的 private
公有办法,也能被抠出来执行了,几乎引起舒服了。
单例模式加强
一个容易被疏忽的问题是:可序列化的单例类有可能并不单例!
举个代码小例子就分明了。
比方这里咱们先用 java
写一个常见的「动态外部类」形式的单例模式实现:
public class Singleton implements Serializable {
private static final long serialVersionUID = -1576643344804979563L;
private Singleton() {}
private static class SingletonHolder {private static final Singleton singleton = new Singleton();
}
public static synchronized Singleton getSingleton() {return SingletonHolder.singleton;}
}
而后写一个验证主函数:
public class Test2 {public static void main(String[] args) throws IOException, ClassNotFoundException {
ObjectOutputStream objectOutputStream =
new ObjectOutputStream(new FileOutputStream( new File("singleton.txt") )
);
// 将单例对象先序列化到文本文件 singleton.txt 中
objectOutputStream.writeObject(Singleton.getSingleton() );
objectOutputStream.close();
ObjectInputStream objectInputStream =
new ObjectInputStream(new FileInputStream( new File("singleton.txt") )
);
// 将文本文件 singleton.txt 中的对象反序列化为 singleton1
Singleton singleton1 = (Singleton) objectInputStream.readObject();
objectInputStream.close();
Singleton singleton2 = Singleton.getSingleton();
// 运行后果竟打印 false!System.out.println(singleton1 == singleton2);
}
}
运行后咱们发现:反序列化后的单例对象和原单例对象并不相等 了,这无疑没有达到咱们的指标。
解决办法是 :在单例类中手写readResolve()
函数,间接返回单例对象,来躲避之:
private Object readResolve() {return SingletonHolder.singleton;}
这样一来,当反序列化从流中读取对象时,readResolve()
会被调用,用其中返回的对象代替反序列化新建的对象。
没想到
本认为这篇会很快写完,后果又扯出了这么多货色,不过这样一梳理、一串联,感觉还是清晰了不少。
就这样吧,
起源:开源中国
作者:CodeSheep
原文:序列化 / 反序列化,我忍你很久了 – hansonwang 的个人空间 – OSCHINA