简单来说，序列化就是将对象转换为字节流，反序列化就是将字节流转化为对象。
Java的对象序列化将那些实现了Serializable接口的对象转换为一个字节序列，并能够在以后将这个字节序列完全恢复为原来的对象。这一过程甚至可通过网络进行；这意味着序列化机制能自动弥补不同操作系统之间的差异。也也就是说，可以在运行Windows系统的计算机上创建一个对象，将其序列化，通过网络将它发送个一台运行Unix系统的计算机，然后在那里准确地重新组装，而却不必担心数据在不同机器上的表示会不同，也不必关心字节的顺序或者其他的任何细节。
对象的序列化可以利用它实现轻量级持久化。“持久性”意味着一个对象的生存周期并不取决于程序是否正在执行；它可以生存于程序的调用之间。通过将一个序列化对象写入磁盘，然后在重新调用程序时恢复该对象，就能够实现持久性的效果。之前写到的Session的持久化策略就是使用了序列化的方式进行了实现（保持对象的状态）。
- 序列化输出到文件，读取文件反序列化为对象。如tomcat实现session持久化
- 网络传输，发送方序列化对象为字节流，接收方反序列化为对象。如dubbo的hessian
dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它
hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式
json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想 在通常情况下，这四种主要序列化方式的性能从上到下依次递减。 但hessian是一个比较老的序列化实现了，而且它是跨语言的，所以不是单独针对java进行优化的。而dubbo RPC实际上完全是一种Java to Java的远程调用，其实没有必要采用跨语言的序列化方式（当然肯定也不排斥跨语言的序列化）。
高效序列化方式： 专门针对Java语言的：Kryo，FST等等 跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack等等 这些序列化方式的性能多数都显著优于hessian2（甚至包括尚未成熟的dubbo序列化）。 其中Kryo是一种非常成熟的序列化实现，已经在Twitter、Groupon、Yahoo以及多个著名开源项目（如Hive、Storm）中广泛的使用。而FST是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例，但我认为它还是非常有前途的。
如果被序列化的类中不包含无参的构造函数，则在Kryo的序列化中，性能将会大打折扣，因为此时我们在底层将用Java的序列化来透明的取代Kryo序列 化。所以，尽可能为每一个被序列化的类添加无参构造函数是一种最佳实践（当然一个java类如果不自定义构造函数，默认就有无参构造函数）。
Java原生序列化、hessian都需实现Serializable接口，另外，Kryo和FST本来都不需要被序列化都类实现Serializable接口，但我们还是建议每个被序列化类都去实现它，因为这样可以保持和Java序列化以及dubbo序列化的兼容性，另外也使我们未来采用上述某些自动注册机制带来可能。
参考资料： json：https://blog.csdn.net/qq_22650745/article/details/75579403