为何要implements Serializable，反序列化是什么？

问题

使用对象，当内存中的对象写入到硬盘的时候，当用套接字在网络上传送对象的时候，当通过RMI传输对象的时候
（调用一个远程对象的方法（通过JNDI服务获取计算机目标对象的引用，将对象从B传送到A，需要实现序列化接口。））
为了保证数据传输的可靠 性，常常要implements Serializable，那么为什么？
对象本质上是虚无缥缈的，只是内存中的一个地址，如果想要让对象持久化，让对象在网络上传输，总不可能传送一个内存地址过去，因此需要将对象描述为一个字节文件，就为网络传输提供了可能，这样当对方接收到这个字节文件，就能根据字节文件快速重建对象，存储在硬盘上也一样，当拿到这个字节文件，读取后对象便建立了

解释

序列化是什么？

序列化：把对象转换为字节序列的过程称为对象的序列化。
反序列化：把字节序列恢复为对象的过程称为对象的反序列化。

即是将数据持久化存储而已，把内存里面的这些对象给变成一连串的字节(bytes)描述的过程。
常见的就是变成文件


下面是摘自 jdk api 文档里面关于接口 Serializable 的描述
类通过实现 java.io.Serializable 接口以启用其序列化功能。
未实现此接口的类将无法使其任何状态序列化或反序列化。
可序列化类的所有子类型本身都是可序列化的。因为实现接口也是间接的等同于继承。
序列化接口没有方法或字段，仅用于标识可序列化的语义

一个类序列化很简单

public class FlyPig implements Serializable {}

Serializable是一个空接口，没有什么具体内容，只是简单的标识一个类的对象可以被序列化。
往往Serializable还需要设置一个serialVersionUID

private static final long serialVersionUID = 1L;

问题就在这个serialVersionUID上
序列化往往和反序列化一起使用
UID保证了反序列时数据的一致性，可恢复性

UID不指定会怎样？

如果序列化时不指定UID，JDK会自动生成一个UID序列化保存，即已经将此UID保存到硬盘中
下次如果反序列化此对象，受到电脑JDK环境不同，或者原来的对象新增了或者删除了某个方法，再次生成的UID会不同，比如自动生成的UID从12345变化为了45678，这将导致原先的数据无法读取，
太可怕了，如果已经存储在硬盘上的数据，网络上传输的数据，RMI传输对象的数据，或者是数据库中的数据，因为一个隐藏的UID无法比对导致数据无法读取，一个项目基本就废了
所以implements Serializable必须给UID赋值，比如1L，下次读取时还是1L就能读取了

这个serialVersionUID的值在存数据库的时候，存哪里了？

数据库没有使用Java这一套序列化，而是不同db各自实现了一套自己的序列化
所以java和数据库各玩各的，只要保证自己不出问题就行，就跟Java的这个UID静态属性没关系了
所以即使你没实现这个Java的序列化的接口，也可以正常的存db，取db

序列化类的内部成员变量有要求吗？

序列化的类的所有成员变量是不是都要是基本类型或实现Serializable接口的类型？

当属性是对象的时候，如果这个对象，没实现序列化接口，那么就会报错NotSerializableException
因此需要都需要实现序列化接口才可以

基本类型无所谓

序列化的类的内部静态变量也会被序列化吗？

除了UID是静态的，JDK亲生的，可以被序列化，其他的静态变量不会被序列化，就是不保存的意思
比如定义了

static public string a="1"

序列化后，修改为

static public string a="2"

读取之前的反序列化文件，a为2，之前的数据丢失了

反序列化有要求吗？

一个没有implements Serializable的类是不能被反序列化的，就是没有序列化的类不能被反序列化