还记得电影《功夫》中火云邪神的一句话:天下功夫,无坚不破,唯快不破。在程序员的世界中,“快”一直是大家苦苦修炼,竞相追逐的终极目标之一,甚至到了“不择手段”、“锱铢必较”的地步。
一直使用json游离于各种编程语言和系统之间。一个偶然的机会碰到了Fastjson,被他的无依赖、易使用、应用广等特性深深吸引的同时,更被他出奇的“快”所震惊,在java界犹如一骑绝尘,旁人只能望其项背。很自然的一个想法涌上心头:FastJSON为何如此之快?于是定神来拔一拔其实现,一则膜拜大师的杰作,二则虚心偷技,三则方便来者学习。
本篇接下来的内容是基于FastJSON 1.1.40,着重讲述其序列化、反序列化实现,最后分析FastJSON为何如此“fast”的原因。
1. 序列化
所谓序列化,就是将java各种对象转化为json串。不多说,先上图。
序列化入口
平常我们经常用到的是JSON.toJSONString()这个静态方法来实现序列化。其实JSON是一个抽象类,该类实现了JSONAware(转为json串)和JSONStreamAware(将json串写入Appendable中)的接口,同时又是JSONArray(内部实现就是个List)和JSONObject(内部实现就是个Map)的父类。JSON.toJSONString()方法内部实现基本相同,为做某些特定配置,对外暴露的接口可能不同。该方法的实现实际托付给了JSONSerializer类。
序列化组合器
JSONSerializer类相当于一个序列化组合器,它将上层调用、序列化配置、具体类型序列化实现、序列化字符串拼接等功能组合在一起,方便外部统一调用。该类有几个重要的成员,SerializeConfig、SerializeWriter、各种Filter列表、DateFormat、SerialContext等,还有每次对各个具体对象序列化的ObjectSerializer(非JSONSerializer的成员变量)。下面就来挨个说明其各自功能。
1. SerializeConfig
SerializeConfig是全局唯一的,它继承自IdentityHashMap,IdentityHashMap是一个长度默认为1024的Hash桶,每个桶存放相同Hash的Entry(可看做链表节点,包含key、value、next指针、hash值)做成的单向链表,IdentityHashMap实现了HashMap的功能,但能避免HashMap并发时的死循环。
SerializeConfig的主要功能是配置并记录每种Java类型对应的序列化类(ObjectSerializer接口的实现类),比如Boolean.class使用BooleanCodec(看命名就知道该类将序列化和反序列化实现写到一起了)作为序列化实现类,float[].class使用FloatArraySerializer作为序列化实现类。这些序列化实现类,有的是FastJSON中默认实现的(比如Java基本类),有的是通过ASM框架生成的(比如用户自定义类),有的甚至是用户自定义的序列化类(比如Date类型框架默认实现是转为毫秒,应用需要转为秒)。当然,这就涉及到是使用ASM生成序列化类还是使用JavaBean的序列化类类序列化的问题,这里判断根据就是是否Android环境(环境变量"java.vm.name"为"dalvik"或"lemur"就是Android环境),但判断不仅这里一处,后续还有更具体的判断。
2. SerializeWriter
SerializeWriter继承自Java的Writer,其实就是个转为FastJSON而生的StringBuilder,完成高性能的字符串拼接。该类成员如下:
- char buf[]
- static ThreadLocal> bufLocal
- int features
表示含义为:双引号filedName and 忽略transientField and enum类型使用String写入 and 排序输出field。 支持的所有特征在SerializerFeature类中,用户可在调用时显示配置,也可通过JSONFiled或JSONType注入配置。
- Writer
举个例子吧,writeStringWithDoubleQuote()表示用字符串用双引号写入,看看如何拼接字符串的。
3. Filter列表
SerializeWriter中有很多Filter列表,可视为在生成json串的各阶段、各地方定制序列化,大致如下:
- BeforeFilter :序列化时在最前面添加内容
- AfterFilter :序列化时在最后面添加内容
- PropertyFilter :根据PropertyName和PropertyValue来判断是否序列化
- ValueFilter :修改Value
- NameFilter :修改key
- PropertyPreFilter :根据PropertyName判断是否序列化
4. DateFormat
指定日期格式。若不指定,FastJSON会自动识别如下日期格式:
- ISO-8601日期格式
- yyyy-MM-dd
- yyyy-MM-dd HH:mm:ss
- yyyy-MM-dd HH:mm:ss.SSS
- 毫秒数值
- 毫秒字符串
- .Net Json日期格式
- new Date()
5. SerialContext
序列化上下文,在引用或循环引用中使用,该值会放入references的Hash桶(IdentityHashMap)缓存。
6. ObjectSerializer
ObjectSerializer只有一个接口方法,如下:
可见,将JSONSerializer传入了ObjectSerializer中,而JSONSerializer有SerializeWriter成员,在每个具体ObjectSerializer实现中,直接使用SerializeWriter拼接字符串即可;Object即是待序列化的对象;fieldName则主要用于组合类引用时设置序列化上下文;而fieldType主要是为了泛型处理。
JSONSerializer中通过public ObjectSerializer getObjectWriter(Class clazz)函数获取类对应的序列化类(即实现ObjectSerializer接口的类),大致逻辑如下:
整个过程是先获取已实现基础类对应的序列化类,再通过类加载器获取自定义的AutowiredObjectSerializer序列化类,最后获取通过createJavaBeanSerializer()创建的序列化类。通过该方法会获取两种序列化类,一种是直接的JavaBeanSerializer(根据类的get方法、public filed等JavaBean特征序列化),另一种是createASMSerializer(通过ASM框架生成的序列化字节码),优先使用第二种。选择JavaBeanSerializer的条件为:
- 该clazz为非public类
- 该clazz的类加载器在ASMClassLoader的外部,或者clazz就是 Serializable.class,或者clazz就是Object.class
- JSONType的注解指明不适用ASM
- createASMSerializer加载失败
结合前面的讨论,可以得出使用ASM的条件:非Android系统、非基础类、非自定义的AutowiredObjectSerializer、非以上所列的使用JavaBeanSerializer条件。
具体基础类的序列化方法、JavaBeanSerializer的序列化方法和ASM生成的序列化方法可以参见代码,这里就不做一一讲解了。
2. 反序列化
所谓反序列化,就是将json串转化为对应的java对象。还是先上图。
同样是JSON类作为反序列化入口,实现了parse()、parseObject()、parseArray()等将json串转换为java对象的静态方法。这些方法的实现,实际托付给了DefaultJSONParser类。
DefaultJSONParser类相当于序列化的JSONSerializer类,是个功能组合器,它将上层调用、反序列化配置、反序列化实现、词法解析等功能组合在一起,相当于设计模式中的外观模式,供外部统一调用。同样,我们来分析该类的几个重要成员,看看他是如何实现纷繁的反序列化功能的。
1. ParserConfig
同SerializeConfig,该类也是全局唯一的解析配置,其中的boolean asmEnable同样判断是否为Andriod环境。与SerializeConfig不同的是,配置类和对应反序列类的IdentityHashMap是该类的私有成员,构造函数的时候就将基础反序列化类加载进入IdentityHashMap中。
2. JSONLexer
JSONLexer是个接口类,定义了各种当前状态和操作接口。JSONLexerBase是对JSONLexer实现的抽象类,类似于序列化的SerializeWriter类,专门解析json字符串,并做了很多优化。实际使用的是JSONLexerBase的两个子类JSONScanner和JSONLexerBase,前者是对整个字符串的反序列化,后者是接Reader直接序列化。简析JSONLexerBase的某些成员:
- int token
由于json串具有一定格式,字符串会根据某些特定的字符来自解释所表示的意义,那么这些特定的字符或所处位置的字符在FastJSON中就叫一个token,比如"(","{","[",",",":",key,value等,这些都定义在JSONToken类中。
- char[] sbuf
解析器通过扫描输入字符串,将匹配得到的最细粒度的key、value会放到sbuf中。
- static ThreadLocal> SBUF_REF_LOCAL
上面sbuf的空间不释放,在下次需要的时候直接拿出来使用,从避免的内存的频繁分配和gc。
- features
反序列化特性的配置,同序列化的feature是通过int的位或来实现其特性开启还是关闭的。默认配置是: AutoCloseSource | UseBigDecimal | AllowUnQuotedFieldNames | AllowSingleQuotes | AllowArbitraryCommas | AllowArbitraryCommas | SortFeidFastMatch | IgnoreNotMatch ,表示检查json串的完整性 and 转换数值使用BigDecimal and 允许接受不使用引号的filedName and 允许接受使用单引号的key和value and 允许接受连续多个","的json串 and 使用排序后的field做快速匹配 and 忽略不匹配的key/value对。当然,这些参数也是可以通过其他途径配置的。
- hasSpecial
对转义符的处理,比如'\0','\'等。
词法解析器是基于预测的算法从左到右一次遍历的。由于json串具有自身的特点,比如为key的token后最有可能是":",":"之后可能是value的token或为"{"的token或为"["的token等等,从而可以根据前一个token预判下一个token的可能,进而得知每个token的含义。分辨出各个token后,就可以获取具体值了,比如scanString获取key值,scanFieldString根据fieldName获取fieldValue,scanTrue获取java的true等等。其中,一般会对key进行缓存,放入SymbolTable(类似于IdentityHashMap)中,猜想这样做的目的是:应用解析的json串一般key就那么多,每次生成开销太多,干脆缓存着,用的就是就来取,还是空间换时间的技巧。
3. List< ExtraTypeProvider >和List< ExtraProcessor >
视为对其他类型的处理和其他自定义处理而留的口子,用户可以自己实现对应接口即可。
4. DateFormat
同序列化的DateFormat,不多说了。
5. ParseContext 和 List< ResolveTask >
ParseContext同序列化的SerialContext,为引用甚至循环引用做准备。
List< ResolveTask >当然就是处理这种多层次甚至多重引用记录的list了。
6. SymbolTable
上面提到的key缓存。
7. ObjectDeserializer
跟ObjectSerializer也是相似的。先根据fieldType获取已缓存的解析器,如果没有则根据fieldClass获取已缓存的解析器,否则根据注解的JSONType获取解析器,否则通过当前线程加载器加载的AutowiredObjectDeserializer查找解析器,否则判断是否为几种常用泛型(比如Collection、Map等),最后通过createJavaBeanDeserializer来创建对应的解析器。当然,这里又分为JavaBeanDeserializer和asmFactory.createJavaBeanDeserializer两种。使用asm的条件如下:
- 非Android系统
- 该类及其除Object之外的所有父类为是public的
- 泛型参数非空
- 非asmFactory加载器之外的加载器加载的类
- 非接口类
- 类的setter函数不大于200
- 类有默认构造函数
- 类不能含有仅有getter的filed
- 类不能含有非public的field
- 类不能含有非静态的成员类
- 类本身不是非静态的成员类
使用ASM生成的反序列化器具有较高的反序列化性能,比如对排序的json串可按顺序匹配解析,从而减少读取的token数,但如上要求也是蛮严格的。综上,FastJSON反序列化也支持基础反序列化器、JavaBeanDeserializer反序列化器和ASM构造的反序列化器,这里也不做一一讲解了。
3. Why So Fast
FastJSON真的很快,读后受益匪浅。个人总结了下快的原因(不一定完整):
1. 专业的心做专业的事
不论是序列化还是反序列化,FastJSON针对每种类型都有与之对应的序列化和反序列化方法,就针对这种类型来做,优化性能自然更具针对性。自编符合json的SerializeWriter和JSONLexer,就连ASM框架也给简化掉了,只保留所需部分。不得不叹其用心良苦。
2. 无处不在的缓存
空间换时间的想法为程序员屡试不爽,而作者将该方法用到任何细微之处:类对应的序列化器/反序列化器全部存起来,方便取用;解析的key存起来,表面重复内存分配等等。
3. 不厌其烦的重复代码
我不知道是否作者故意为之,程序中出现了很多类似的代码,比如特殊字符处理、不同函数对相同token的处理等。这样虽对于程序员寻求规整相违背,不过二进制代码却很喜欢,无形之中减少了许多函数调用。
4. 不走寻常路
对于JavaBean,可以通过发射实现序列化和反序列化(FastJSON已有实现),但默认使用的是ASM框架生成对应字节码。为了性能,无所不用其极。
5. 一点点改变有很大的差别
排序对输出仅是一点小小的改变,丝毫不影响json的使用,但却被作者用在了解析的快速匹配上,而不用挨个拎出key。
6. 从规律中找性能
上面也讲到,FastJSON读取token基于预测的。json串自身的规律性被作者逮个正着,预测下一个将出现的token处理比迷迷糊糊拿到一个token再分情况处理更快捷。
结束语
不喜欢虎头蛇尾的结局。不过写到这里,除了承认自己对FastJSON代码某些地方还没看懂或理解有偏颇之外,不敢说太多了。
关于作者:阿里巴巴集团CDO数据开发平台高级工程师,2010年加入阿里巴巴,长期从事各存储系统(mysql、oracle、odps、hadoop、sqlserver、rds、drds、hbase、oceanbase、db2、ots、tair等)间实时和离线的数据同步工作,打造阿里巴巴云上云下的数据同步通道。