javaxmljson序列化_序列化：一个老家伙的咸鱼翻身（Java对象、XML、JSON、反序列化）...

转自&＃xff1a;码农翻身(微信号&＃xff1a;coderising)

1、寒冬的蛰伏

这里的工作很繁忙&＃xff0c;一年365天&＃xff0c; 一天24小时几乎不停工。

但是我却是一个闲人&＃xff0c; 因为我做的工作最近用的人太少了&＃xff0c; 经常被冷落在一边。

大多数时候&＃xff0c;我只能羡慕的看着线程、反射、注解、集合、泛型这些明星员工在那里忙忙碌碌&＃xff0c; 听着他们充满激情的的大声说笑。

他们都叫我序列化&＃xff0c;想想也是&＃xff0c; 我的工作就是把一个Java 对象变成二进制的字节流&＃xff0c; 或者反过来把字节流变成Java 对象&＃xff0c; 这有什么意思&＃xff1f;

当大家需要一个Java 对象的时候&＃xff0c; 直接new 出来不就得了&＃xff0c; 对象不用了自然有令人胆战心惊的垃圾回收去处理。

但是存在即合理&＃xff0c; 在JDk1.1的时代&＃xff0c; 我就已经存在了。

当时人们的思想很超前&＃xff1a; 网络就是计算机。 一个个Java 对象应该可以在网络中到处旅行 &＃xff1a;

从一个机器出发时&＃xff0c;就变成二进制字节流&＃xff0c;顺着网络跨过千山万水&＃xff0c; 到达另外一台机器&＃xff0c;在那里摇身一变&＃xff0c;恢复成Java 对象&＃xff0c; 在那里继续运算。

既然可以以二进制方式在网络中漫游&＃xff0c; 那自然也可以把这些字节流存到硬盘中&＃xff0c; 当JVM停机&＃xff0c;整个世界坍塌以后&＃xff0c; 线程&＃xff0c;反射&＃xff0c;注解都不复存在了&＃xff0c; 而我的字节流还会在硬盘上默默等待&＃xff0c; 等待下一次JVM的重生&＃xff0c; 把对象恢复。

所以我觉得我的工作也很有价值&＃xff0c; 从某种意义上来讲&＃xff0c;

我可以让Java 对象跨越时间和空间而永生 &＃xff01;

这种永生是有代价的&＃xff0c; 首先你必须得用Java&＃xff0c; 这是废话&＃xff0c; 因为我只是java对象序列化。

虽然那二进制字节流的格式是公开的&＃xff0c; 你可以用任何语言(C,C&＃43;&＃43;,Python…)去解析读取&＃xff0c; 但是解析以后又有什么用处呢&＃xff1f; 那些字节流中会告知你这是哪个类的数据&＃xff0c;字段的类型和值&＃xff0c; 但是如果你没有相对应的Java 类&＃xff0c;还是无法构建出Java 对象出来。

其次&＃xff0c; 做序列化双方的类必须得一致&＃xff0c; 要不然肯定出乱子。

大部分人都不知道在上个世纪末和本世纪初&＃xff0c; 我还是随着J2EE火了一阵&＃xff0c; 当时J2EE中有个叫RMI东西&＃xff0c; 其实就是Java RPC。  由于我卓越的工作&＃xff0c; 开发人员用可以轻松的调用远程服务器上的Java 方法&＃xff0c; 就相当于调用本地方法一样&＃xff0c; 很方便。

可惜的是这个RMI只能用在Java环境中&＃xff0c;对于服务器来说这根本不是问题&＃xff0c; 但是当时Web应用正在兴起&＃xff0c; 一个浏览器中是很难有Java环境的&＃xff0c;  所以RMI很快就没落了&＃xff0c; 我也随之被打入冷宫&＃xff0c; 我也只好蛰伏下来&＃xff0c;等待机会。

2、XML和JSON的挑战

后来我们这里来了一个叫XML的小伙子&＃xff0c;很受大家的欢迎&＃xff0c; 都喜欢把Java 对象序列化的工作交给他去做。

我不能坐以待毙&＃xff0c; 我仔细的观察了几天以后&＃xff0c; 终于发现这个家伙有个大缺点&＃xff1a; 太复杂了&＃xff01;

对于我的Java 序列化&＃xff0c;大部分情况下你只需要让你的类实现Serializable接口&＃xff0c; 我就可以接管后续的所有工作。不用你操心了。

可是用XML, 你还得写一堆代码把一个类中的各个字段和他们的值变成XML标签/属性/值 才行。  当用来表示对象的XML字符串漫游到另外一个机器上&＃xff0c; 还得有一堆代码把XML变成对象。

我嘲笑XML说&＃xff1a; “小伙子&＃xff0c; 你这也太麻烦了吧&＃xff0c; 人类的时间多宝贵&＃xff0c; 为了用XML做序列化&＃xff0c;代价好高嗷&＃xff01;”

“老家伙&＃xff0c;没你想的那么复杂&＃xff0c; 你可能不知道&＃xff0c; 我们有些类库能自动帮助把对象变成XML”    他毫不示弱。

“ 不要忘了 ”  小伙子补充道   “ 我们XML可是语言中立的&＃xff0c; 在这里是Java对象&＃xff0c; 到了客户端 什么语言都行 &＃xff0c; Java/C/Python/Ruby… 都没问题&＃xff0c; 甚至浏览器里的Javascript都能处理&＃xff0c; 这一点你不行了吧&＃xff1f;”

这家伙戳到了我的痛处&＃xff0c;  在浏览器中我的确需要一个Java 环境才行运行 &＃xff0c;  唉&＃xff0c;真是成也Java ,败也Java。

我说&＃xff1a; “我知道你是语言无关的&＃xff0c; 但是你注意到没有&＃xff0c; 你的XML标签冗余太多&＃xff0c; 真正的数据很少。 比如有个Person类&＃xff0c; 有两个字段name和address,  用你的XML做序列化就变成了这个样子

abc

&＃xff0c; 这在网络上传输起来绝对是一种浪费&＃xff01; 我的java 字节流就不一样了&＃xff0c; 二进制的&＃xff0c;非常紧凑&＃xff0c;一点都不浪费&＃xff01;“

XML小伙子沉默了&＃xff0c; 小样&＃xff0c; 我也抓住了你的痛点。

过了两天&＃xff0c;这个小伙子又带来了一个叫JSON的小弟&＃xff0c; 他得意洋洋的向我炫耀&＃xff1a; 用了JSON以后&＃xff0c;数据精简多了&＃xff0c; 不信你看&＃xff1a;{“name”&＃xff1a;“abc”, “address”:“xyz”} &＃xff0c; 现在我们不但语言中立&＃xff0c;还很精简&＃xff0c; 老家伙&＃xff0c;这下你无话可说了吧。

我认栽&＃xff0c; 但是让XML也没高兴多久&＃xff0c; 让他没有想到的是&＃xff0c; Web时代JSON和Javascript是一对绝配&＃xff0c; 联手统治了浏览器。 连XML自己都快没饭吃了。

3、新协议的崛起

其实我一直觉得我的二进制序列化方式能减少存储空间&＃xff0c; 方便网络传输&＃xff0c;只是我的硬伤是无法跨越语言。

不行&＃xff0c; 我不能一直守着Java这一亩三分地了&＃xff0c; 必须扩展支持多语言&＃xff0c; 这样才能脱离Java环境。

有人说&＃xff1a; 计算机的所有问题都可以通过增加一个中间层来解决。 我是不是也可以搞个中间层出来&＃xff1f;

让这个中间层来定义/描述消息的格式&＃xff0c;然后再弄一个小翻译器( 不&＃xff0c;叫编译器显的更加高大上)&＃xff0c; 把这个程序员自定义的消息格式转换成各种语言的实现&＃xff0c;例如java, python, c&＃43;&＃43;等等。

在转换好的语言实现里边&＃xff0c;自动包含了要被序列化的类的定义&＃xff0c; 以及实现序列化和反序列化的代码&＃xff0c; 当然序列化以后的数据是二进制的。

等到二进制的字节流通过网络传输到另外一台机器&＃xff0c; 就可以反序列化为各种语言(例如Python)的对象了&＃xff0c; 当然必须是同一个消息格式产生的Python类。

不仅仅是Python, C&＃43;&＃43;, Go, C# , 甚至Javascript 都可以用 &＃xff01;

是不是很爽 &＃xff1f; 既语言中立&＃xff0c; 又采用二进制传输&＃xff0c; 体积小&＃xff0c;解析快&＃xff0c; 完美的综合了各种优点&＃xff01;

唯一的额外工作是需要把消息格式的定义编译成各种语言的实现&＃xff0c; 为了能支持多语言&＃xff0c;这也是没办法的事情 。

我得意的把新方案给XML和JSON这两个家伙看了&＃xff0c; 从表情来看&＃xff0c;就知道他俩如临大敌了。

我也把方案提交给了我们服务器世界的老大 &＃xff0c; 他大为赞赏&＃xff0c; 决定先在部分场景下用起来&＃xff0c; 例如对象存入缓存的时候需要序列化&＃xff0c; 以前用json, 占用空间很大&＃xff0c; 改用了我的新方案以后&＃xff0c; 不但减少了空间使用&＃xff0c; 还提升了读写的效率&＃xff0c; 效果不错。

我成功地扳回了一局&＃xff0c;现在找我用新方案来做序列化的人越来越多了&＃xff0c; 但是最终鹿死谁手还很难说&＃xff0c;最有可能的情况是&＃xff0c;各种方案混合使用&＃xff0c; 即使是这样&＃xff0c;我也很满足了。