本文目录一览：
- 1、SpringCloud使用FastJsonHttpMessageConverter遇到的坑
- 2、为什么springmvc中都用jackson而不用fastjson
- 3、Jackson和FastJson性能谁更快
- 4、idea为什么拉了fastjson包却使用不了
- 5、代码中的命名均不能以下划线或美元符号开为什么
- 6、Gson、FastJson、Jackson、json-lib对比总结
SpringCloud使用FastJsonHttpMessageConverter遇到的坑
1.序列化到前台时时间变成时间戳，没有时间格式，SpringBoot自带的配置时间序列化格式因为已经被替换了实现类所以不在生效，需要使用fastJson的时间设置方式@JSONField(format ="yyyy-MM-dd HH:mm:ss")在实体类上加上次注解即可。
2.在序列话到前台时候fastjson遍历集合会存在对象被返回的情况，以及所有请求被拦截，但是处理不是很理想的情况，贴出配置供参考
FastJsonHttpMessageConverterCustomextends 当作一个Bean注册
public class FastJsonHttpMessageConverterCustomextends FastJsonHttpMessageConverter {
private static SetsupportedMediaTypes;
public FastJsonHttpMessageConverterCustom() {
supportedMediaTypes =new HashSet();
supportedMediaTypes.add(MediaType.APPLICATION_JSON);
supportedMediaTypes.add(MediaType.APPLICATION_JSON_UTF8);
}
@Override
public boolean canRead(Type type, Class contextClass, MediaType mediaType) {
return this.supports(contextClass) supportedMediaTypes.contains(mediaType);
}
@Override
public boolean canWrite(Type type, Class clazz, MediaType mediaType) {
return super.supports(clazz) supportedMediaTypes.contains(mediaType);
}
@Override
protected void writeInternal(Object object, HttpOutputMessage outputMessage)throws IOException, HttpMessageNotWritableException {
OutputStream out = outputMessage.getBody();
String text = JSON.toJSONString(object, SerializerFeature.DisableCircularReferenceDetect);
byte[] bytes = text.getBytes("utf-8");
out.write(bytes);
}
}
为什么springmvc中都用jackson而不用fastjson
这是spring默认的，你也可以重写，用fastjson代替
jackson，事实上fastjson确实比
jackson快一些。而且不会发现自包含类型数据的转换错误。
Jackson和FastJson性能谁更快
Fastjson快，但是和jackson 的差距不大，优势并没有太明显。Jackson还可以加上AfterBurner来使用byte generation，这样和Fastjson的差距就更小了。
除了速度胜出外，Fastjson相比较 Jackson 有不少短板。
1. 可定制性
Jackson有灵活的API，可以很容易进行扩展和定制，而且很多时候需要的模块都已经有人提供了。比如guava中定义的数据类型，比如kotlin语言Immutable的类型等，比如java8 引入的新日期时间类型和Optional都已经有支持的模块。
FastJson只有一个(简陋)的SerializeFilter机制用来定制序列化，ParseProcess机制用来定制反序列化，每次调用序列化/反序列化的的时候都要自己传filter或者Process这个参数过去，Jackson和 Gson都是直接注册模块就可以了，Jackson还可以使用SPI来自动发现和注册模块。
2. 代码质量
公司有一些项目使用了fastjson，在使用fastjson的项目里面碰到的两个低级bug:
1. 碰到在128~255 的字符直接异常，这些主要是西欧语言的字符，因为他用一个数组来记录 转义后的字符表示，但是数组长度只有128...
2. 内存占用过多。Fastjson为了性能，在ThreadLocal中缓存了char[] buffer，这样避免分配内存和gc的开销。但是如果碰到了大的json(比如10M这样的)，就会占用大量的内存，而且以后都是处理小json了内存占用也回不来。
这些问题虽然后来的版本都修复了，但是也反映出Fastjson代码质量上要求不够严格。 而Jackson这么多年来使用上还没有碰到过这样的Bug.
3. 文档
英文文档缺乏已有的也不规范，相比较国内用户还多些。
idea为什么拉了fastjson包却使用不了
JSON.toJSONString(o,SerializerFeature.DisableCircularReferenceDetect);解决方法~默认fastjson是打开索引引用的。如果是null对象，或者对象多特定情况下，引用就会出$ref等字眼。解决方法，关闭索引。
代码中的命名均不能以下划线或美元符号开为什么
因为阿里自研的fastjson对_和$开头的变量序列化bug太多，而jackson，gson就没这些问题
Gson、FastJson、Jackson、json-lib对比总结
综上4种Json技术的比较： 在项目选型的时候可以使用Google的Gson和阿里巴巴的FastJson两种并行使用，
如果只是功能要求，没有性能要求，可以使用google的Gson，
如果有性能上面的要求可以使用Gson将bean转换json确保数据的正确，使用FastJson将Json转换Bean
2.1 主要类介绍
Gson类：解析json的最基础的工具类
JsonParser类：解析器来解析JSON到JsonElements的解析树
JsonElement类：一个类代表的JSON元素
JsonObject类：JSON对象类型
JsonArray类：JsonObject数组
TypeToken类：用于创建type，比如泛型List?
2.2 maven依赖
2.3 bean转换json
2.4 json转换bean
2.5 json转换复杂的bean，比如List，Set
将json转换成复杂类型的bean,需要使用TypeToken
2.6 通过json对象直接操作json以及一些json的工具
a) 格式化Json
b) 判断字符串是否是json,通过捕捉的异常来判断是否是json
c) 从json串中获取属性
d) 除去json中的某个属性
e) 向json中添加属性
f) 修改json中的属性
g) 判断json中是否有属性
h) json中日期格式的处理
然后使用gson对象进行json的处理，如果出现日期Date类的对象，就会按照设置的格式进行处理
i) json中对于Html的转义
这种对象默认对Html进行转义，如果不想转义使用下面的方法
3.1 maven依赖
3.2 基础转换类
同上
3.3 bean转换json
将对象转换成格式化的json
将对象转换成非格式化的json
obj设计对象
对于复杂类型的转换,对于重复的引用在转成json串后在json串中出现引用的字符,比如 [0].books[1]
3.4 json转换bean
3.5 json转换复杂的bean，比如List，Map
3.6 通过json对象直接操作json
a) 从json串中获取属性
b) 除去json中的某个属性
c) 向json中添加属性
d) 修改json中的属性
e) 判断json中是否有属性
f) json中日期格式的处理
使用JSON.toJSONStringWithDateFormat,该方法可以使用设置的日期格式对日期进行转换
4.1 maven依赖
4.2 基础转换类
同上
4.3 bean转换json
a)将类转换成Json,obj是普通的对象，不是List，Map的对象
b) 将List，Map转换成Json
4.4 json转换bean
4.5 json转换List,对于复杂类型的转换会出现问题
4.6 json转换Map
4.7 json对于日期的操作比较复杂，需要使用JsonConfig,比Gson和FastJson要麻烦多了
创建转换的接口实现类，转换成指定格式的日期
4.8 JsonObject 对于json的操作和处理
a) 从json串中获取属性
b) 除去json中的某个属性
c) 向json中添加和修改属性，有则修改，无则添加
d) 判断json中是否有属性
fastjson 和 jackson 在把对象序列化成json字符串的时候，是通过反射遍历出该类中的所有getter方法；
Gson 是通过反射遍历该类中的所有属性。
所以， 在定义POJO中的布尔类型的变量时，不要使用isSuccess这种形式，而要直接使用success 。
以上为网上摘抄，以下为实际项目中使用结果。
实体类为 BaseVO.java :
用Gson 将该实体类转成json时报以下异常：
原因是：子类和父类有相同的字段属性;
解决方法：
(1)重命名重复字段。因为重复的字段在第三方包中，所以该方法在本例中不可行。
(2)将实体类中需要打印的字段加上注解 @Expose ，（本例将该类所有有get方法的属性都加上了） ：
新建gson：
excludeFieldsWithoutExposeAnnotation 排除掉没有Expose注解的属性。
或者在不需要解析的字段前面加上 transient :
用该方式，没有报异常了，解析结果（加注解 @Expose 或加 transient ）如下：
但从结果来看，那些直接调用第三方api获取值的属性没有解析，因为第三方的类无法加上 @Expose注解 ，导致这些属性为 null ,而 Gson默认的规则不会解析为 null 的属性 ，比如：
(3)换解析方式：使用FastJson。
因为FastJson是通过getter方法获取属性，并把其值序列化成json字符串的，所以这里，我们这个实体类中去掉不想被解析的属性的get方法，变成如下：
fastJson、JackJson以及Gson序列化对象与get、set以及对象属性之间的关系
