Serializable接口解读

Serializable 接口

作为 Java 中那些绕不开的内置接口 Serializable这个接口的全限定名（包名 + 接口名）是 java.io.Serializable，这里给大家说个小技巧，当你看到一个类或者接口的包名前缀里包含java.io那就证明这个类 / 接口它跟数据的传输有关。

Serializable 是 Java 中非常重要的一个接口，如果一个类的对象是可序列化的，即对象在程序里可以进行序列化和反序列化，对象的类就一定要实现Serializable接口。那么为什么要进行序列化和反序列化呢？

序列化的意思是将对象的状态转换为字节流；反序列化则相反。换句话说，序列化是将 Java 对象转换为静态字节流（序列），然后我们可以将其保存到文件、数据库或者是通过通过网络传输，反序列化则是在我们读取到字节流后再转换成 Java 对象的过程；这也正好解释了为什Serializable 接口会归属到java.io包下面。

Serializable 是一个标记型接口

虽说需要进行序列化的对象，它们的类都需要实现 Serializable 接口，但其实你会发现，我们在让一个类实现 Serializable 接口时，并没有额外实现过什么抽线方法。

import java.io.Serializable;

public class Person implements Serializable {
    private String name;
    private int age;
}

比如向上面个类文件里的内容，Person 类声明实现 Serializable 接口后，并没有去实现什么抽象方法，IDE 也不会用红线警告提示我们：“你有一个抽象方法需要实现” ，原因是 Serializable 接口里并没有声明抽象方法。

public interface Serializable {
}

这种不包含任何方法的 interface 被称为标记型接口，类实现 Serializable接口不必实现任何特定方法，它只起标记作用，让 Java 知道该类可以用于对象序列化。

serializable Version UID

虽说一个类实现了 Serializable 接口的时候不需要实现特定的方法，但是经常会看到一些实现了Serializable的类中，都有一个名为serialVersionUID类型为long的私有静态 属性。

import java.io.Serializable;

public static class Person implements Serializable {

    private static final long serialVersionUID = -7792628363939354385L;

    public String name;
    public int    age;
}

该属性修饰符里使用了final即赋值后不可更改。Java 的对象序列化 API 在从读取到的字节序列中反序列化出对象时，使用 serialVersionUID 这个静态类属性来判断：是否序列化对象时使用了当前相同版本的类进行的序列化。Java 使用它来验证保存和加载的对象是否具有相同的属性，确保在序列化上是兼容的。

大多数的 IDE 都可以自动生成这个 serialVersionUID静态属性的值，规则是基于类名、属性和相关的访问修饰符。任何更改都会导致不同的数字，并可能导致 InvalidClassException。 如果一个实现 Serializable 的类没有声明 serialVersionUID，JVM 会在运行时自动生成一个。但是，强烈建议每个可序列化类都声明 serialVersionUID，因为默认生成的serialVersionUID依赖于编译器，因此可能会导致意外的InvalidClassExceptions。

Java 序列化与JSON序列化的区别

Java 的序列化与现在互联网上 Web 应用交互数据常用的 JSON 序列化并不是一回事儿，这是咱们需要注意的，像 Java、C#、PHP 这些编程语言，都有自己的序列化机制把自家的对象序列化成字节然后进行传输或者保存，但是这些语言的序列化机制之间并不能互认，即用 Java 把对象序列化成字节、通过网络 RESTful API 传给一个 PHP 开发的服务，PHP 是没办法反序列化还原出这个对象的。这样才有了 JSON、XML、Protocol Buffer 这样的更通用的序列化标准。

Java序列化相较于 JSON 的优势

上面介绍了 JSON 这样的通用序列化格式的优势，有的可能会问了，那还用 Java 序列化干啥。这里再给大家分析一下，Java 对象序列化虽然在通用性上不如 JSON 那些序列化格式，但是在 Java 生态内部却是十分好用的，其最聪明的一点是，它不仅能保存对象的副本，而且还会跟着对象里面的reference，把它所引用的对象也保存起来，然后再继续跟踪那些对象的reference，以此类推。

是不是所有的bean都需要进行序列化？

首先第一个问题，实现序列化的两个原因：

1、将对象的状态保存在存储媒体中以便可以在以后重新创建出完全相同的副本；

2、按值将对象从一个应用程序域发送至另一个应用程序域。实现serializabel接口的作用是就是可以把对象存到字节流，然后可以恢复，所以你想如果你的对象没实现序列化怎么才能进行持久化和网络传输呢，要持久化和网络传输就得转为字节流，所以在分布式应用中及设计数据持久化的场景中，你就得实现序列化。

第二个问题，是不是每个实体bean都要实现序列化，答案其实还要回归到第一个问题，那就是你的bean是否需要持久化存储媒体中以及是否需要传输给另一个应用，没有的话就不需要，例如我们利用fastjson将实体类转化成json字符串时，并不涉及到转化为字节流，所以其实跟序列化没有关系。

第三个问题，有的时候并没有实现序列化，依然可以持久化到数据库。这个其实我们可以看看实体类中常用的数据类型，例如Date、String等等，它们已经实现了序列化，而一些基本类型，数据库里面有与之对应的数据结构，从我们的类声明来看，我们没有实现serializabel接口，其实是在声明的各个不同变量的时候，由具体的数据类型帮助我们实现了序列化操作。

另外需要注意的是，在NoSql数据库中，并没有与我们Java基本类型对应的数据结构，所以在往nosql数据库中存储时，我们就必须将对象进行序列化，同时在网络传输中我们要注意到两个应用中javabean的serialVersionUID要保持一致，不然就不能正常的进行反序列化。