背景(最近查明了fastjson新的远程代码执行漏洞后，立即催促(吐槽)项目小组修改，真的无法修改，无法承受项目的繁多和陈旧)。 考虑到不同项目所依赖的fastjson版本不同，这次我们将重点讨论fast JSON1.2. 16版中遇到的哪些问题？
兼容性：低版本没问题，高版本抛异常
一、提出问题。提取部分代码片段，稍加改造如下。
import com.Alibaba.fast JSon.JSon阵列；
import com.Alibaba.fast JSon.JSon对象；
导入Java.util .数组列表；
导入Java.UTIL.Hashmap；
导入Java.util .列表；
汇入Java.util .地图；
//*
* *是* fastjson坑啊。
*
* @author一猿小讲
*/
公共类t
publicstaticvoidmain (字符串[ ]数组) {
Jon对象RET JSON=新JSON对象(；
retJSON.put(retcode，) 0000 )；
retJSON.put(retmsg，)按需购买；
列表字符串，对象列表=网络映射，对象(；
映射，对象重置映射=新建hashmap字符串，对象(；
ret map.put (顺序，) O010000088888 )；
retmap.put('payername )，'擅长撒娇的项链'；
ret列表添加(ret地图；
ret JSon.Put (重置列表)、重置列表)；
if (ret JSon.contains key (' ret列表' ) ) )
jsonarrayjsonarray=ret JSON.getjsonarray (' ret list )；
for (对象： JSon阵列) {
jsonobjectorderobject=(JSON对象)对象；
System.out.println ('假装执行的处理=='订单对象)；
}
}
}
{1}引入依赖关系(低版本) :
从属关系
groupIdcom.alibaba/groupId
artifactIdfastjson/artifactId标识
版本1.2.16 /版本
/dependency代码开始跑(爽，像飞一样) :
假装要执行的处理==={'orderId':'O010000088888 '，' payerName': '撒娇项链' }此时，将fastjson升级为高版本
从属关系
groupIdcom.alibaba/groupId
artifactIdfastjson/artifactId标识
版本1.2.70 /版本
(/dependency代码开始奔跑)波涛起伏，万里sqdds永远流泪) :
exceptioninthread ' main ' Java.lang.classcastexception 3360 Java.util.Hashmapcannotbecastttocom.Alibaba.Fast JSon.Hashmapcanotbe
at.main(t.Java:31 )显然是第31行代码引发了异常
jsonobjectorderobject=(JSON对象)对象； 而且很明显，java.util.HashMap无法转换为com.Alibaba.fast JSON.JSON对象。
二、版本1.2.16没问题，但升级到版本1.2.70会抛出异常。 那是为什么？
分析一：用fast JSON1.2. 16版捕捉虫子。
5bb51e0f3d1f1?from=pc">分析二：fastjson 1.2.70 版本下捉虫子。
版本 1.2.16 vs 版本 1.2.70：
两幅图的标注 1 对比着看，会发现低版本的 JSONArray 中存进去的是 JSONObject，而高版本的存进去的是 HashMap；两幅图的标注 2 对比着看，会发现低版本中 JSONObject 强转成 JSONObject，当然没问题，而高版本拿 HashMap 强转成 JSONObject 就会出现 ClassCastException。到这儿，感觉还不是很解气，势必要打破砂锅刨到底！
版本 1.2.16 的源码刨到底：
而顺着版本 1.2.16 的源码一路看到底，会发现会对 Map 进行二次封装处理，最终会包装成 JSONObject 对象（这或许就是能强转成 JSONObject 的原因，存进去的是牛，强转成牛，当然没问题）。
版本 1.2.70 的源码刨到底：
版本 1.2.70 vs 版本 1.2.16，很显然 1.2.70 版本增加了一个集合的条件分支判断，如果根据 key 获取的 value 是 List，则会构建 JSONArray 对象，如下面源码截图示意，List 里面的值不会做变化，如果 List 中放入的是 Map，则不会对 Map 进行二次处理（这可能就是强制转换成 JSONObect 失败的原因，存进去的是牛，非要强转成马，当然行不通）。
三、该怎么解决版本升级，带来的兼容性问题呢？
很简单，既然高版本的没有对 list 中的 Object 进行转换，咱们就刻意调用 toJSON 方法进行转换一番。
retJson.put("retList", retList); 修改为 retJson.put("retList", JSON.toJSON(retList));代码跑起来，Debug 看看效果如何：
很明显，JSONArray 中获取的 object 类型已变为 JSONObject，当然在 1.2.16、1.2.70 版本跑起来都畅通无阻，那么版本升级带来的问题就迎刃而解。
四、闲扯淡（走心）
写代码时候还是需要注意点，能稍微规范些，就尽量按照规范，就如本次提到的问题，向 JSONObject 中加入 List<Map<String,Object> 时，不妨先提前 toJSON 转换一番，这样版本升级也不会有问题。由于依赖包升级导致不兼容的情况很常见，不过绝大多数都是向下兼容的，例如 JDK ... 5、6、7、8 ...，所以如果你正在开发核心代码，若涉及到版本更新，尽量考虑兼容性问题，如果涉及到老功能废弃时，不妨采用注解标注一下，这样后人会尽早发现问题。不规范的传入：导致内存溢出
分享一段有意思的代码，一起享受其中乐趣。
import com.alibaba.fastjson.JSON; /** * fastjson 坑啊！ * @author 一猿小讲 */ public class T { public static void main(String[] args) { String str = "{"key1":"\value1"}"; Object obj = JSON.parse(str); System.out.println(obj); } }代码能跑起来，运行结果绝对正常
{"key1":"u000Balue1"}此时，我们动点手脚，把 value1 的值变掉
String str = "{"key1":"\x";程序运行，word 天，惊呆！
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.alibaba.fastjson.parser.JSONLexerBase.putChar(JSONLexerBase.java:2835) at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:866) at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:428) at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1302) at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1268) at com.alibaba.fastjson.JSON.parse(JSON.java:137) at com.alibaba.fastjson.JSON.parse(JSON.java:128) at T.main(T.java:11)好奇不？咋回事？Debug 分析一番就清楚啦。
当 json 字符串是以 x 结尾时，由于低版本的 fastjson 并未对其进行校验，将会导致其继续尝试获取字符。
由于 index>= this.len 始终成立，则意味着会直接获取到 u001A，相当于 26，带来的结果就是 isEOF 永远为 false，意味着要无休止的读下去。
就这样陷入了死循环 1-->2-->3-->1，直到内存溢出。
Debug 一趟肯定比我说的要清楚，当然，此问题早已在版本 1.2.60 中修复。
1.2.70 版本肯定也不会有此问题啦，在高版本下直接提示格式错误啦，摆脱了内存溢出。
Exception in thread "main" com.alibaba.fastjson.JSONException: invalid escape character x at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:984) at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:479) at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1401) at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1367) at com.alibaba.fastjson.JSON.parse(JSON.java:183) at com.alibaba.fastjson.JSON.parse(JSON.java:193) at com.alibaba.fastjson.JSON.parse(JSON.java:149) at T.main(T.java:11)走心：
金无足赤人无完人，代码有 Bug 很正常，需要一步一步去迭代，要敢于让团队犯错、试错、容错。
通过此段测试，项目开发中参数格式校验就很有必要。
寄语写最后
本次，仅以项目中依赖 fastjson 类库作为切入点，主要想传达：在使用三方轮子时，尽可能做对三方的轮子了如指掌，知己知彼方能百战不殆。
另外，借助 fastjson 升级的事情，也想传达写出规范性的代码，是很有必要，不然升级的时候就很麻烦。代码修炼系列分享，仍会结合实际项目进行继续分享，请各位持续关注。
（一）改掉这些坏习惯，还怕写不出健壮的代码？
（二）改掉这些坏习惯，还怕写不出优雅的代码？
（三）改掉这些坏习惯，还怕写不出优雅的代码？
（四）改掉这些坏习惯，还怕写不出健壮的代码？
（五）改掉这些坏习惯，还怕写不出精简的代码？
（六）改掉这些坏习惯，还怕写不出精简的代码？
好了，本次就谈到这里，一起聊技术、谈业务、喷架构，少走弯路，不踩大坑。欢迎关注「一猿小讲」，会持续输出原创精彩分享，敬请期待！