fastJson看书记录

看了阿里的逆流而上，里面提到的fastJson的坑，记录一下
what happen：

"hidden":{
"xx":true;
"xxx":true
}

"hidden"：true

class a{
    private Hidden hidden;
    private boolean status;
    public boolean isHidden{
        return status;
    }
    public Hidden getHidden{
        return hidden;
    }
}

序列号前后不一样，不同机器上不一样，看起来像随机选了一个

why:
fastJson（1.2.4版本）是通过getter方法去进行序列化/反序列化的：
通过调用java.lang.Class.getMethods方法来获取javaBean的Getters来做反序列化
fastJson通过getMethods去遍历方法，找到的第一个方法，就是他认为需要的那个getter方法，而jvm中，加载getHidden 和isHidden 的时候，顺序是随机的，所以就导致出现了不同机器上，可能出现加载内容不一样的情况

explain more
在jvm加载getters方法的时候，顺序为：
1，挨个解析方法列表，并为每个方法分配内存；
2，挨个把解析后的method存进一个methods列表；
3，对分配完毕的方法列表，按照方法的symbol（方法地址）进行重排序；
4，当持有对象地址的时候（而不知道对象名字的时候），就可以在列表上通过折半查找（二分查找） ，快速的定位到具体的方法（名字）
因为在分配内存地址期间，内存可能发生释放，就导致后面方法分配到的内存地址，不一定比前面的方法大或小，内存地址和方法之间的关系不是线性对应的，而是乱序的

how to reslove:
1，升级二方包，新版本中，fastJson做了名字优先级的选择
2，和开发者达成共识，不允许出现没有对应变量的getter方法，删掉这个代码
3，

more info
为什么有的地方没问题？因为jackson：
有的部门使用的是jackson
它和fastjson的区别是：
fastjson要求被解析的类一定要符合javabean规范（空参构造函数，set，get method）
而jackson只要求是pojo即可（是个java类就行了）
业务中使用jackson，基于Field对象本身来解析，可以避免getter方法不唯一的问题。

then
改进措施
1，不直接使用引入的二方包，而是在业务中按照业务要求再定义一个类来专供业务处理，与第三方类之间可以通过适配器模式来保持联系与进行隔离（解耦）。这样就能防止二方包有坑或者有变动坑到自己。
在引入第三方代码的时候，都应该有一个隔离层，在隔离层中明确使用的业务功能，（比如ossManager,用来上传图片到某节点，隔离层中可以有配置代码，少量基础判断功能，供外界业务层调用）通过设计模式来将第三方提供的实现隔离在业务代码之外，便面多余的功能特性或者缺陷影响到自己的代码。（这样在我们自己的业务层调用的时候，可以不关注那些多余的乱七八糟的功能，只调用我们自己封装好的，偏业务的功能）。
2，记录日志，通过日志排查问题，但是要平衡日志和高并发之间的影响