共计 6417 个字符,预计需要花费 17 分钟才能阅读完成。
本文 Github 开源项目:github.com/hansonwang99/JavaCollection 中已收录,有详细自学编程学习路线、面试题和面经、编程资料及系列技术文章等,资源持续更新中 …
工具人
曾几何时,对于 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()
会被调用,用其中返回的对象替代反序列化新建的对象。
没想到
本以为这篇会很快写完,结果又扯出了这么多东西,不过这样一梳理、一串联,感觉还是清晰了不少。
就这样吧,下篇见。
本文 Github 开源项目:github.com/hansonwang99/JavaCollection 中已收录,有详细自学编程学习路线、面试题和面经、编程资料及系列技术文章等,资源持续更新中 …
慢一点,才能更快