概念
Java中号称一切皆是对象，在Java程序运行过程中，都是借助对象来完成一系列我们想要的操作。但是对象它是存储在内存中的，如果我们机器关机了，这些对象也就不存在了。序列化就是将这些在内存中运行的对象的状态信息转换为一种可以存储到磁盘上的过程，或者将对象的信息状态进行传输的过程。在序列化期间，我们可以将当前对象的状态写入到一个临时的存储区或者持久化到硬盘中，这样对象的信息就可以长久存储于硬盘介质中，或者可以在网络间进行传输。
有正向就有反向，对象信息持久化的过程是序列化过程，那么逆向就是反序列化过程，也就是说可以通过读取已经持久化到硬盘上的对象信息，将其重新转变成对象应用于应用程序中。序列化和反序列化应用很广泛，我们常说的远程调用，Hibernate的持久化等等，这些都需要用到序列化和反序列化。
怎样使用序列化
Serializable接口
首先最常见就是这个序列化标识接口，说它是标识是因为它的接口源码中其实什么都没有定义，纯粹只是为了标识而使用，一个类只有实现了这个接口，我们才能对它进行序列化，否则是会报错的。序列化和反序列化的过程需要用到ObjectInputStream和ObjectOutputStream。
public class User implements Serializable{
private String name;
private int age;
private Data birthday;
private static final long serialVersionUID = 1L;
//...省略getter和setter
@Override
public String toString() {
return "User{" +
"name='" + name + "'" +
"age=" + age +
",birthday=" + birthday;
}
}
这里面的serialVersionUID主要是用于反序列化的时候做匹配用的，只有serialVersionUID的值一致，最后反序列化的时候才认为它们是同一种类型，如果不定义，程序会默认生成一个1L。在反序列化的时候，就是依据这个值来跟当前虚拟机中的类中定义的数值比对，如果一致，才会认为是同一个版本，否则即使其他部分完全一样，也无法顺序反序列化。
然后对User做一个简单的序列化demo，代码如下：
public class Demo1 {
public static void main(String[] args) {
User user = new User();
user.setName("Jack");
user.setAge(20);
user.setBirthday(new Date());
//将对象序列化并写入文件中
ObjectOutputStream oos = null;
try {
oos = new ObjectOutputStream(new FileInputStream("D:\\tempFile"));
oos.writeObject(user);
} catch (Exception e) {
e.printStackTrace();
} finally {
if (oos != null) {
try {
oos.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
//读取tempFile中的内容，将其再次转换为内存中的对象（反序列化）
File file = new File("D:\\tempFile");
ObjectInputStream ois = null;
try {
ois = new ObjectInputStream(new FileInputStream(file));
User newUser = (User)ois.readObject();
System.out.println(newUser);
} catch (Exception e) {
e.printStackTrace();
} finally {
if (ois != null) {
try {
ois.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
}
}
上面就是一个简单的利用Java API进行序列化的操作，如果User类没有实现Serializable接口，再次运行程序的时候会发现，它在writeObject的时候会报错：java.io.NotSerializableException。仔细想想应该也能猜个大概：一定是writeObject方法中在进行序列化的时候，对传入的对象进行了Serializable类型的判断，只有实现了它才能继续进行序列化。
Externalizable接口
这个接口其实是继承了Serializable，它更加灵活一点，它里面定义了writeExternal和readExternal两个方法分别用于序列化和反序列化使用。通过这两个方法，我们可以自己决定需要序列化那些数据。如果对象中涉及到很少的属性需要序列化，大多数属性无需序列化，这种情况使用Externalizable接口是比较灵活的。当然Serializable也同样能实现只序列化出一部分属性，只要将不需要序列化的属性前面加一个trasient修饰符即可。
具体它的使用方式与前面Serializable接口的使用方式几乎一样，只是需要在实现了Externalizable接口的类中实现writeExternal和readExternal方法，在方法里面自己定义写出的属性，如：
public void writeExternal(ObjectOutput out) throws IOException {
//这里只写入了name和gender
out.writeObject(name);
out.writeObject(gender);
}
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
//注意读取的顺序与write的顺序保持一致
name = (String)in.readObject();
age = (String)in.readObject();
}
以上这两种序列化方式都是Java原生提供的序列化API，在一些特殊需求的场景中，可以借助于第三方包来实现序列化，例如：可以通过jackson包，利用ObjectMapper来实现JSON式的序列化；fastjson同样也能实现json式序列化；还有比较有名的hessian序列化，hessian更加侧重于数据，有些场景下它的性能是比较好的，但是它也有有些不适用的场景，主要还是因为它的内部原理特性决定的。
hessian序列化
首先它的一个最大特色就是跨语言，hessian提供了一整套的byte[]的写入规范。这样其他语言在实现hessian序列化的时候就可以参照这套的标准规范，从而达到不同语言之间的兼容效果，因此hessian的序列化都是围绕这byte数组来的。来看一下它的简单使用：
<!-- 首先需要引入hessian包 -->
<!-- https://mvnrepository.com/artifact/com.caucho/hessian -->
<dependency>
<groupId>com.caucho</groupId>
<artifactId>hessian</artifactId>
<version>4.0.38</version>
</dependency>
public static <T> byte[] serialize(T obj) {
byte[] bytes = null;
ByteArrayOutputStream bos = new ByteArrayOutputStream();
HessianOutput hessianOutput = new HessianOutput(bos);
try {
//obj必须实现Serializable接口
hessianOutput.writeObject(obj);
bytes = bos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return bytes;
}
@SuppressWarnings("unchecked")
public static <T> T deserialize(byte[] data) {
if (data == null) return null;
ByteArrayInputStream bis = new ByteArrayInputStream(data);
HessianInput hessianInput = new HessianInput(bis);
Object object = null;
try {
object = hessianInput.readObject();
} catch (IOException e) {
e.printStackTrace();
}
return (T)object;
}
主要的序列化和反序列化的过程都在这里了。需注意一点的是：这里一定要使用HessianOutput和HessianInput，因为在编写代码时会发现，IDE还会提示一个Hessian2Output和Hessian2Input，这是两个不同的版本，Hessian2的使用方法需要去查阅具体的文档。另外经过Hessian序列化出来的内容要比原生的Java序列化暂用空间要少，这是因为Hessian内部做了一些优化操作。此外还有protobuf序列化，它是Google的一个序列化开发工具，如果有需要，可以到网上查阅相关信息，目前还没遇到过使用protobuf的情况，这里就不赘述了。
除此之外，还有其他的一些序列化方案（比如：avro，kryo等等），而且那些序列化方式我没有用过，所以这里就不再一一分析使用了，如果有需要，可以网上搜索一下，基本资料比较齐全了。
不同的序列化方式，各自的优缺点都不同，但是可以确定的是：第三方的序列化工具都会对序列化的结果做一定的优化，可以使得序列化的结果更加精简，占用空间更少，但是这些都是有代价，更少的空间占用，就意味着更多的时间去解析。对于普通的序列化需求，Java的原生API已经可以满足，除非特别特殊的场景需要使用第三方工具的某些特性，否则没必要纠结于到底哪种性能更好，只有哪种更合适而已。试想：如果出现一个很完美的序列化方案，其他的序列化方式早就被淘汰了，既然存在，就一定有独到之处。
Java原生序列化原理
在此之前首先看一个例子：Java中有一个类叫ArrayList，开发中我们会经常遇到，稍微了解ArrayList源码设计的都应该知道，它的内部实际上是维护了一个Object数组elementData作为数据的存储容器。对于ArrayList对象的增删改查实际上都是对这个elementData进行操作得出的结果，而且ArrayList是实现了Serializable接口的，所以它是可以被序列化的，但是它的elementData这个属性前面加了一个transient修饰符，前面介绍过，如果属性中加了transient修饰符，在序列化的时候是会被忽略的，那么问题就来了：我们在正常序列化ArrayList对象以后，再对其进行反序列化的时候，其实仍然可以得到它内部存储的那些数据，这是怎么做到的？这里就牵扯到了序列化的内部实现原理了，仔细查阅ArrayList源码可以发现，该类中定义了writeObject和readObject两个私有方法，这两个会在序列化的时候使用到。
结合前面的代码示例，可以看到Java原生序列化有两个关键的类：ObjectOutputStream和ObjectInputStream。对于序列化，需要用到ObjectOutputStream的writeObject方法，这里直接给出源码中writeObject内部的调用关系：writeObject --》writeObject0 --》writeOrdinaryObject --》writeSerialData --》invokeWriteObject。（这里的调用关系主要给出的是对于一个普通对象序列化时的调用关系，有些特殊的类型，比如：String，Enum等可能中间有所不一样）。下面是invokeWriteObject方法的源代码
void invokeWriteObject(Object obj, ObjectOutputStream out)
throws IOException, UnsupportedOperationException
{
requireInitialized();
if (writeObjectMethod != null) {
try {
writeObjectMethod.invoke(obj, new Object[]{ out });
} catch (InvocationTargetException ex) {
Throwable th = ex.getTargetException();
if (th instanceof IOException) {
throw (IOException) th;
} else {
throw MiscException(th);
}
} catch (IllegalAccessException ex) {
// should not occur, as access checks have been suppressed
throw new InternalError(ex);
}
} else {
throw new UnsupportedOperationException();
}
}
注意：核心是writeObjectMethod.invoke(obj, new Object[]{ out })这一句。这一句很明显就是一个反射的语法，writeObjectMethod指的就是序列化对象所属类中定义的writeObject方法对象。如果当前对象所属类中没有定义writeObject这么一个方法，就会调用一个默认的defaultWriteFields方法(走defaultWriteFields分支的判断逻辑可在writeSerialData方法中查看)。
现在再来回想前面说过的：如果要对一个对象进行序列化，该对象所属的类必须实现Serializable接口，这是为什么？可以在writeObject0 方法中找到答案：
这是writeObject0 方法中的一段代码：
...
if (obj instanceof String) {
writeString((String) obj, unshared);
} else if (cl.isArray()) {
writeArray(obj, desc, unshared);
} else if (obj instanceof Enum) {
writeEnum((Enum<?>) obj, desc, unshared);
} else if (obj instanceof Serializable) {
writeOrdinaryObject(obj, desc, unshared);
} else {
if (extendedDebugInfo) {
throw new NotSerializableException(
cl.getName() + "\n" + debugInfoStack.toString());
} else {
throw new NotSerializableException(cl.getName());
}
}
...
可以看到，第三个else if 判断中对obj进行了类型判断，判断其是否是Serializable类型，说明前面的猜想是对的。除此之外：它还进行了String，数组以及枚举类型的判断。所以说如果待序列化的对象如果是上面的任何一种都可以进行序列化，否则会抛出NotSerializableException。
根据同样的思路可以查阅ObjectInputStream源码中的readObject方法调用链：readObject --》readObject0 --》 readOrdinaryObject --》readSerialData --》invokeReadObject。
可以发现：反序列化中的调用链跟序列化中的调用链非常相似。所以分析它的原理完全可以参照序列化中分析思路。它同样在invokeReadObject方法内部有一句核心的反射调用：readObjectMethod.invoke(obj, new Object[]{ in });利用反射调用readObject方法（如果对象所属类自定义了该方法）。如果没有，在readSerialData方法中就会直接走defaultReadFields方法，而不会走invokeReadObject方法了。而且在readObject0方法中也存在了大量的类型判断，而且用的是switch-case，具体可以查阅源码，这里就不再贴出代码了。
现在再来考虑：为什么ArrayList需要这么设计它的序列化方式，直接序列化elementData不是也可以？其实这是一个空间存储效率的问题，因为在正常的使用场景中，elementData数组内部其实都是存不满的，可以说99%的情况都不会满，而数组是固定长度的，剩余的空间其实存储的都是null。如果直接序列化elementData中的内容，就会发现有很多null也被序列化出来的，但是这些内容是完全没用的，这就浪费了效率和存储空间。而ArrayList定义了writeObject方法，恰恰就解决了这个问题，在该方法中将elementData数组内部真正有用的数据序列化出去，这样既节约了空间，又提高了效率。
序列化的使用场景
持久化操作或网络传输
一个最常见的场景就是持久化操作，将对象作为一种数据存储到某种介质中一遍将来复用，这时就会使用到序列化技术，不同的是实现序列化依赖的技术不同，但是核心仍然是序列化的概念。
同样的对于需要进行网络减传输的，也需要对其进行序列化，否则对象只能存在与当前虚拟机的内存中，无法通过夸虚拟机，跨网络的数据通信，比如：现在常用的一些消息中间件，核心功能就是消息的传递，而且是不在不同环境下的消息传递，需要大量的数据在网络中传输，如果没有序列化，这些传输是完全无法完成的。
这个是所有使用场景的核心，其它的应用场景基本不会逃出这持久化和网络传输这两个概念。
RPC框架
也就是远程调用框架，例如dubbo，本质上说，远程调用就必须将对象序列化后通过网络传输到远程调用机器上，这样远程调用的机器无需实现具体的对象，仅仅通过网络，就可以完成一系列原本无法在本地完成的工作。而且RPC的调用方式极大的保护了代码的安全，发放给调用端的可能仅仅是定义的一些接口，但是在调用端使用的时候，它的具体实现的类的对象则是由网络传输提供，这样避免了代码的泄露风险。
其实RPC的序列化核心场景就是：网络传输。
缓存
现在比较热门的话题之一，现在系统中几乎必不可少的一个模块，为了提高系统的响应速度，我们可能会用到大量的缓存，有些缓存是纯内存级别的，就是程序关闭后，数据丢失。但是现在一些缓存框架，如：Redis等，可以实现定期的持久化，用以保证程序出现问题时不会完全丢失数据，可能只是丢失很少一部分数据。这个持久化的过程就需要涉及到序列化。
缓存序列化核心场景：持久化操作。
其他
单例中的序列化安全问题
面试中常常被问到的一个问题就是：单例模式的几种实现方式。这里可以强烈推荐H大的 单例模式的七种实现。但是大多的单例模式设计方案都无法保证序列化下的安全，换句话说：在将对象序列化以后，再次进行反序列化，可以绕过单例模式的检查机制，从而导致内存中存在两个甚至更多个相同类型的对象，这对于单例模式来说是破坏性的，因为单例的原则就是：运行期间，内存中只会存在一个对象。常用的一种解决方案就是使用readResolve()方法来避免此事发生(可网上搜索相关用法，比较简单)。
在七种单例模式的写法当中，有一种采用枚举的方式，它是《Effective Java》作者Josh Bloch提倡使用的一种方式，虽然在实际应用中很少使用这种方式（因为枚举方式的应用场景非常狭小，很多场景下是不能使用的）。但是Josh Bloch既然提倡使用，肯定是有一定道理的。
写法简单
首先枚举单例的写法非常简单，三行代码即可搞定：
public enum Singleton{
INSTANCE;
}
枚举类型可以自己处理序列化
前面在分析序列化的时候，可以发现，在writeObject0方法中其实是有枚举类型的判断的。而且Java的规范中明确说明了：每一个枚举类型及其定义的枚举变量在JVM中都是唯一的，在枚举类型的序列化和反序列化上，Java做了特殊的规定：在对枚举对象进行序列化的时候，Java仅仅是将枚举对象的name属性输出，在反序列化的时候，通过java.lang.Enum的valueOf方法，根据name查找对应的枚举对象；同时编译器不允许任何对该序列化过程的定制。禁用了writeObject、readObject、readObjectNoData、writeReplace和readResolve方法。
简单来说就是：Java对枚举类型的序列化和反序列化有特殊规定，不允许定制，那些传统的方法全部失效，而且序列化写出的时候只有一个name属性，反序列化的时候，在虚拟机中通过name查找相应的枚举对象。而且枚举对象在虚拟机内部是唯一的。
所以说枚举类型的安全性保障是JVM提供的，它是非常可靠的。
枚举实例的创建是线程安全的
现在以前面的Singleton的枚举写法为例，使用cfr工具对其进行反编译可以看到：
//使sugarenums参数设置为false，可以得到较为详细的编译结果
root@ubuntu:/usr/local/workspace/demo3# java -jar ../cfr_0_132.jar Singleton.class --sugarenums false
/*
* Decompiled with CFR 0_132.
*/
public final class Singleton extends Enum<Singleton> {
public static final /* enum */ Singleton INSTANCE = new Singleton();
private static final /* synthetic */ Singleton[] $VALUES;
public static Singleton[] values() {
return (Singleton[])$VALUES.clone();
}
public static Singleton valueOf(String string) {
return Enum.valueOf(Singleton.class, string);
}
private Singleton() {
super(string, n);
}
static {
$VALUES = new Singleton[]{INSTANCE};
}
}
可以看到，Singleton实际上是继承了Enum类，并且将其定义成成了final类型，无法被继承了。它的内部几乎都是static属性的，static类型的属性会在类被加载之后被初始化。当一个Java类第一次被真正使用到的时候，会对它的静态资源（static修饰）进行初始化以及Java类的加载，这个过程是线程安全的。这个线程安全是虚拟机保证的，所以说它同样是可靠的。
