本篇内容介绍了“fastjson漏洞导致服务瘫痪问题分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！ 2019年9月5日，fastjson修复了当字符串中包含x转义字符时可能引发OOM的问题。建议广大用户升级fastjson版本至少到1.2.60。
一个bug这么恐怖，竟然直接OOM，亲身体验下吧。测试代码如下：实验效果：4分钟 堆内存 占用上升达2G； fastjson升级几天后，一老系统业务发生异常，异常信息如下： 看这错误，肯定是json字符串格式有误，应该是冒号的地方实际上是等号了，然后导致反序列化异常，果断排查接口入参，结果入参一切正常。纳尼。。。
好吧，那就本地debug吧，结果竟然在本地复现异常了，震惊！！！再次检查接口入参，没有问题，和以前正常运行的入参是一致的。想到最近升级fastjson了，还原fastjson版本试试吧。还原后还真是正常了！！！ 难道fastjson版本升级出了大bug？ 本着对阿里技术的信任，我决定一探究竟。 待反序列化的数据，其格式是2层List嵌套，测试代码已做脱敏处理（完整源码见后文github地址）： 好奇宝宝们就不要纠结于为什么没有定义好实体再使用TypeReference一步到位啦，千年老代码确实是这样的，这也不是本文的重点。
经过debug发现，jsonArrayB.get(0).toString()的值是 {names=[zxiaofan]}。注意了，names后面是等号，不是冒号，这也就能解释为什么异常是“expect ‘:’ at 0, actual =”了。
但为什么升级后就异常，没升级就一切正常呢？继续研究下，梳理后发现如下值得注意的地方：1、fastjson版本时1.2.54时正常，大于1.2.54后便会异常；2、运行代码是Google的Gson和阿里的fastjson混用的（json处理全部换成fastjson一切正常）； 莫非，是fastjson升级后和Google的Gson不兼容导致？仿佛看到了曙光。 对比分析了fastjson 1.2.54版本和其之后的版本（以下以1.2.55版本为例），发现getJSONArray(String key)还真有区别。 经过调试后发现，1.2.54版本在getJSONArray(String key)方法中使用的是(JSONArray)toJSON(value)，而1.2.55版本在getJSONArray(String key)方法中使用的是return new JSONArray((List)value)。两者处理后返回的数据也确实不同。fastjson 1.2.54 版本：fastjson 1.2.55 版本： 从调试情况看，1.2.54版本最终返回的是JSONObect，1.2.55版本返回的是LinkedTreeMap。Map结构toString()的结构肯定是“key=value”，而不是json结构。
但是如果将测试代码中的GSON.fromJson替换成JSON.parseObject，那么不论fastjson的版本高低，都能正常运行。 至此，我们知道了，fastjson在升级到1.2.55及以上版本后，getJSONArray方法对Google的Gson处理后的数据兼容性降低，或许本文的名字叫做《fastjson与Gson混用引发的bug》更合适。
也不知道这算不算是bug，给官方提了个issue： > fastjson版本升级降低了对Gson的兼容性 #2814。 在分析的过程中，看了fastjson中getJSONArray方法对各种数据类型的处理方式，和自己以前写的类似代码相比fa 香港云主机stjson的代码更优雅，值得学习。相关方法com.alibaba.fastjson.JSON.toJSON()，有兴趣的同学可以看看。“fastjson漏洞导致服务瘫痪问题分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注开发云网站，小编将为大家输出更多高质量的实用文章！
事务代码：MR21 概念： 如果在期间中外部采购的原材料和半成品已出现明显的价格波动 ， 可手动更改这些物料的标准价格。 在一个期间内只能 发布 一次标准成本估算。这样可确保成本核算结果在给定期间内保持一致。这会产生以下影响： ● 如果在同一期间内尝试第二次发…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
