把对象转换为字节序列的过程称为对象的序列化 。
把字节序列恢复为对象的过程称为对象的反序列化 。
对象的序列化主要有两种用途：
1） 把对象的字节序列永久地保存到硬盘上，通常存放在一个文件中；
2） 在网络上传送对象的字节序列。
在很多应用中，需要对某些对象进行序列化，让它们离开内存空间，入住物理硬盘，以便长期保存。比如最常见的是Web服务器中的Session对象，当有 10万用户并发访问，就有可能出现10万个Session对象，内存可能吃不消，于是Web容器就会把一些seesion先序列化到硬盘中，等要用了，再把保存在硬盘中的对象还原到内存中。
当两个进程在进行远程通信时，彼此可以发送各种类型的数据。无论是何种类型的数据，都会以二进制序列的形式在网络上传送。发送方需要把这个Java对象转换为字节序列，才能在网络上传送；接收方则需要把字节序列再恢复为Java对象。
java.io.ObjectOutputStream代表对象输出流，它的writeObject(Object obj)方法可对参数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。
java.io.ObjectInputStream代表对象输入流，它的readObject()方法从一个源输入流中读取字节序列，再把它们反序列化为一个对象，并将其返回。
只有实现了Serializable和Externalizable接口的类的对象才能被序列化。Externalizable接口继承自 Serializable接口，实现Externalizable接口的类完全由自身来控制序列化的行为，而仅实现Serializable接口的类可以 采用默认的序列化方式 。
对象序列化包括如下步骤：
1） 创建一个对象输出流，它可以包装一个其他类型的目标输出流，如文件输出流；
2） 通过对象输出流的writeObject()方法写对象。
对象反序列化的步骤如下：
1） 创建一个对象输入流，它可以包装一个其他类型的源输入流，如文件输入流；
2） 通过对象输入流的readObject()方法读取对象。
输出如下
输出如下
在序列化时显示指定serialVersionUID作为版本号，凡是实现Serializable接口的类都有一个表示序列化版本标识符的静态变量，如果不显示指定，jvm会隐式给我们随机生成一个serialVersionUID，这个serialVersionUID是根据对象的信息生成的，如果我们对序列化对象有所改动的话，serialVersionUID也会随之改动，再反序列化就会因serialVersionUID不一致而报错、
示例：
序列化和反序列化跟上面一样
反序列化
此时是正常且成功的，但是，我们如果现在在User对象新增一个属性
上面我说，serialVersionUID是根据对象信息生成的，现在对象多了一个属性，信息已经改变，再次生成的serialVersionUID 已经和刚才的不一样了，这时我们再进行反序列化会报如下错误
我们指定serialVersionUID后就可以随意修改了
序列化（serialization）在计算机科学的数据处理中，是指将数据结构或对象状态转换成可取用格式（例如存成文件，存于缓冲，或经由网络中发送），以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，可以利用它来产生与原始对象相同语义的副本。对于许多对象，像是使用大量引用的复杂对象，这种序列化重建的过程并不容易。面向对象中的对象序列化，并不概括之前原始对象所关系的函数。这种过程也称为对象编组（marshalling）。从一系列字节提取数据结构的反向操作，是反序列化（也称为解编组、deserialization、unmarshalling）。
序列化在计算机科学中通常有以下定义:
序列化与反序列化为数据交换提供了可能，但是因为传递的是字节码，可读性差。在应用层开发过程中不易调试，为了解决这种问题，最直接的想法就是将对象的内容转换为字符串的形式进行传递。具体的传输格式可自行定义，但自定义格式有一个很大的问题——兼容性，如果引入其他系统的模块，就需要对数据格式进行转换，维护其他的系统时，还要先了解一下它的序列化方式。为了统一数据传输的格式，出现了几种数据交换协议，如：JSON, Protobuf，XML。这些数据交换协议可视为是应用层面的序列化/反序列化。
如前所述，序列化和反序列化的出现往往晦涩而隐蔽，与其他概念之间往往相互包容。为了更好了让大家理解序列化和反序列化的相关概念在每种协议里面的具体实现，我们将一个例子穿插在各种序列化协议讲解中。在该例子中，我们希望将一个用户信息在多个系统里面进行传递；在应用层，如果采用 .net 语言，所面对的类对象如下所示：
JSON中的元素都是键值对——key:value形式，键值对之间以":"分隔，每个键需用双引号引起来，值的类型为String时也需要双引号。其中value的类型包括：对象，数组，值，每种类型具有不同的语法表示。
基础类型
对象
数组
说到XML就不得不介绍下SOAP（Simple Object Access protocol），SOAP 是一种被广泛应用的，基于 XML 为序列化和反序列化协议的结构化消息传递协议。SOAP 在互联网影响如此大，以至于我们给基于 SOAP 的解决方案一个特定的名称 --Web service。SOAP 虽然可以支持多种传输层协议，不过 SOAP 最常见的使用方式还是 XML+HTTP。SOAP 协议的主要接口描述语言（IDL）是 WSDL（Web Service Description Language）。SOAP 具有安全、可扩展、跨语言、跨平台并支持多种传输层协议。如果不考虑跨平台和跨语言的需求，XML 的在某些语言里面具有非常简单易用的序列化使用方法，无需 IDL 文件和第三方编译器
实际使用中具体要使用哪个协议，我们可以从上列出的几个特性进行综合考虑
序列化协议一方面要能摆脱语言、平台的束缚；另一方面要在业界耳熟能详应用广泛。比如Java标准的对象序列化实现就不是这一条的好榜样，你要一个C程序员将Java标准序列化实现的数据反序列化成对应结构体是一个很蛋疼的事情。相反，JSON就是一个很好的序列化协议，至少在这一条上算得上是佼佼者了。
序列化协议要能方便开发过程中的调试。做过二进制协议开发的同学一定深有体会，肉眼基本不可辨别序列化后的数据，需要借助一些第三方的工具一点点分析。相对于二进制协议，文本协议就比较和蔼可亲了。
协议要能够经得住时间的考验。一般情况下采用公开流行的协议是不存在这个问题的，因为他们都被成千上万的应用检验过了。特别要小心的是自定义协议，举个反例，比如自定义一个类似于Java标准序列化协议的协议，由于当前业务没有涉及到对象和对象之间的继承关系，所以协议制定者没有考虑对象继承的情况。但是随着业务的发展，系统中出现了继承关系的实体类，某个同事不小心将这种对象的实例序列化，结果可想而知。协议不够成熟，所以自定义协议需要考虑的因数很多。如果自己不是大牛，建议不要自定义序列化协议。
和稳定性差不多，满足通用性条件的协议基本不会出现这个问题。问题还是会出现在自定义协议上。协议的成熟是一个漫长的过程，要经过不断的测试。比如稳定性中出现的那个问题，协议将继承关系的序列化加入，升级之后就能解决问题。但是要做到兼容以前的版本就不那么容易了。协议的制定者也不是圣人，不可能考虑得那么周全，但是一定要有一套可扩展的方案，这样协议才能存活下来，慢慢迭代成稳定版本。
说道性能问题，无非就是时间和空间的博弈。序列化结果数据的大小，直接影响网络传输的带宽和磁盘存储的空间。序列化和反序列化过程所消耗的时间长短，影响系统的性能。几种常用的协议性能的比较网上有很多，这里就不详细介绍了。
![sublime text 3中编译less弹出：[Decode error - output not utf-8]](/aiimages/sublime+text+3%E4%B8%AD%E7%BC%96%E8%AF%91less%E5%BC%B9%E5%87%BA%EF%BC%9A%5BDecode+error+-+output+not+utf-8%5D.png)
