fastjson反序列化一个字段有多个set方法时
2018-02-04 · 知道合伙人数码行家
huanglenzhi
知道合伙人数码行家
向TA提问 私信TA
知道合伙人数码行家
采纳数:117538
获赞数:517188
长期从事计算机组装,维护,网络组建及管理。对计算机硬件、操作系统安装、典型网络设备具有详细认知。
向TA提问 私信TA
关注
展开全部
1 排查异常
代码打印的异常是读取redis数据之后,fastjson解析出错。将出错代码抽取出一个测试方法,在线上环境进行循环调用来复现问题。
完成代码抽取之后,在循环执行的过程中代码会随机出错,问题没有每次必现。由于升级并没有涉及相关代码的更改,刚开始着重点在排查jar包冲突。通过删除一部分jar包之后问题缓解,但是并没有彻底解决问题。
由于升级过程中涉及两个操作,1,更改hbase实现代码;2,升级jdk版本到1.7 。在排查代码没有头绪的背景下,开始排查jdk版本问题。相同的测试代码在jdk1.6下运行不会出错,但是1.7会有问题。此时推断现有的fastjson版本在jdk1.7下运行会有问题,在尝试更换不同版本jar包后问题仍然存在。
2 fastjson debug
由于必须升级jdk1.7,所以决定开始调试fastjson源码来确定问题点。但是由于问题不是每次都发生,并且调试过程是在win环境下的jdk版本下进行。造成调试过程中始终不出现线上发生的问题。
此时只能按照正常执行的方式进行debug,看看问题可能会出现在哪几个地方。同时在可能出现的问题的代码点添加log信息,重新编译jar包后在线上运行。看看线上运行异常时输出的结果是否与正常运行的情况下产生的一样。
首先发现的是value字段的解析器对象创建错误。
正常情况下,value字段会执行到418行并判断为true,返回ArrayDeserializerd对象对value字段进行解析。线上有问题时该行会判断为false,最后执行到代码430行产生了错误的对象解析器。
在确定了问题代码后,便开始对方法传入的参数进行判断,并与正常逻辑下产生的数据进行对比,层层向上排查。
最终发现代码产生异常的方法:
该方法主要的逻辑是对要反序列化的字段添加属性信息。一解析类为例:该类有三个字段,subtype、timestamp、vaule,该方法会调用反射方法获取该类下所有的set、get方法,然后进行对提取方法中的参数类型并添加到字段属性中。
例如setSubType方法,会提取subtype为属性名称,同时String为属性的类型(这个类型便是导致属性解析器初始化失败的问题来源)。
考虑正常情况,每个属性只有一个set方法对属性进行赋值,不会出现问题。但是此处的value字段比较特殊。它在thrif定义文件中为binary类型,对应的类中产生了两个set方法,并且参数类型不一样:
针对每个属性的创建,只会在处理第一个set方法时进行添加,之后处理该属性的其他set方法时,会首先在保存的map中判断该属性对应的对象是否已经添加,如果添加过则直接返回。在正常运行程序时,会先处理setValue(byte[]value) 方法,value会对应byte[]类型。 但是如果处理的为setValue(ByteBuffer value) 则会将value属性关联为ByteBuffer类型。最终导致程序运行出错。
也就是说getMethods()方法返回setvalue方法的顺序不同导致了问题的发生,经验证jdk1.6下setValue(byte[]value)始终排在setValue(ByteBuffer value)之前;而jdk1.7下会有后者在前的情况
代码打印的异常是读取redis数据之后,fastjson解析出错。将出错代码抽取出一个测试方法,在线上环境进行循环调用来复现问题。
完成代码抽取之后,在循环执行的过程中代码会随机出错,问题没有每次必现。由于升级并没有涉及相关代码的更改,刚开始着重点在排查jar包冲突。通过删除一部分jar包之后问题缓解,但是并没有彻底解决问题。
由于升级过程中涉及两个操作,1,更改hbase实现代码;2,升级jdk版本到1.7 。在排查代码没有头绪的背景下,开始排查jdk版本问题。相同的测试代码在jdk1.6下运行不会出错,但是1.7会有问题。此时推断现有的fastjson版本在jdk1.7下运行会有问题,在尝试更换不同版本jar包后问题仍然存在。
2 fastjson debug
由于必须升级jdk1.7,所以决定开始调试fastjson源码来确定问题点。但是由于问题不是每次都发生,并且调试过程是在win环境下的jdk版本下进行。造成调试过程中始终不出现线上发生的问题。
此时只能按照正常执行的方式进行debug,看看问题可能会出现在哪几个地方。同时在可能出现的问题的代码点添加log信息,重新编译jar包后在线上运行。看看线上运行异常时输出的结果是否与正常运行的情况下产生的一样。
首先发现的是value字段的解析器对象创建错误。
正常情况下,value字段会执行到418行并判断为true,返回ArrayDeserializerd对象对value字段进行解析。线上有问题时该行会判断为false,最后执行到代码430行产生了错误的对象解析器。
在确定了问题代码后,便开始对方法传入的参数进行判断,并与正常逻辑下产生的数据进行对比,层层向上排查。
最终发现代码产生异常的方法:
该方法主要的逻辑是对要反序列化的字段添加属性信息。一解析类为例:该类有三个字段,subtype、timestamp、vaule,该方法会调用反射方法获取该类下所有的set、get方法,然后进行对提取方法中的参数类型并添加到字段属性中。
例如setSubType方法,会提取subtype为属性名称,同时String为属性的类型(这个类型便是导致属性解析器初始化失败的问题来源)。
考虑正常情况,每个属性只有一个set方法对属性进行赋值,不会出现问题。但是此处的value字段比较特殊。它在thrif定义文件中为binary类型,对应的类中产生了两个set方法,并且参数类型不一样:
针对每个属性的创建,只会在处理第一个set方法时进行添加,之后处理该属性的其他set方法时,会首先在保存的map中判断该属性对应的对象是否已经添加,如果添加过则直接返回。在正常运行程序时,会先处理setValue(byte[]value) 方法,value会对应byte[]类型。 但是如果处理的为setValue(ByteBuffer value) 则会将value属性关联为ByteBuffer类型。最终导致程序运行出错。
也就是说getMethods()方法返回setvalue方法的顺序不同导致了问题的发生,经验证jdk1.6下setValue(byte[]value)始终排在setValue(ByteBuffer value)之前;而jdk1.7下会有后者在前的情况
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询