哈喽大家好啊，我是 Hydra~ 在前面的文章中，我们讲过 Java 中泛型的类型擦除，不过有小伙伴在后台留言提出了一个问题，带有泛型的实体的反序列化过程是如何实现的，今天我们就来看看这个问题。
铺垫
我们选择fastjson来进行反序列化的测试，在测试前先定义一个实体类：
@Datapublic class Foo<T> { private String val; private T obj;}
复制代码
如果大家对泛型的类型擦除比较熟悉的话，就会知道在编译完成后，其实在类中是没有泛型的。我们还是用Jad反编译一下字节码文件，可以看到没有类型限制的T会被直接替换为Object类型：
下面使用fastjson进行反序列化，先不指定Foo中泛型的类型：
public static void main(String[] args) { String jsonStr = "{\"obj\":{\"name\":\"Hydra\",\"age\":\"18\"},\"val\":\"str\"}"; Foo<?> foo = JSONObject.parseObject(jsonStr, Foo.class); System.out.println(foo.toString()); System.out.println(foo.getObj().getClass());}
复制代码
查看执行结果，很明显fastjson不知道要把obj里的内容反序列化成我们自定义的User类型，于是将它解析成了JSONObject类型的对象。
Foo(val=str, obj={"name":"Hydra","age":"18"})class com.alibaba.fastjson.JSONObject
复制代码
那么，如果想把obj的内容映射为User实体对象应该怎么写呢？下面先来示范几种错误写法。
错误写法 1
尝试在反序列化时，直接指定Foo中的泛型为User：
Foo<User> foo = JSONObject.parseObject(jsonStr, Foo.class);System.out.println(foo.toString());System.out.println(foo.getObj().getClass());
复制代码
结果会报类型转换的错误，JSONObject不能转成我们自定义的User：
Exception in thread "main" java.lang.ClassCastException: com.alibaba.fastjson.JSONObject cannot be cast to com.hydra.json.model.User at com.hydra.json.generic.Test1.main(Test1.java:24)
复制代码
错误写法 2
再试试使用强制类型转换：
Foo<?> foo =(Foo<User>) JSONObject.parseObject(jsonStr, Foo.class);System.out.println(foo.toString());System.out.println(foo.getObj().getClass());
复制代码
执行结果如下，可以看到，泛型的强制类型转换虽然不会报错，但是同样也没有生效。
Foo(val=str, obj={"name":"Hydra","age":"18"})class com.alibaba.fastjson.JSONObject
复制代码
好了，现在请大家忘记上面这两种错误的使用方法，代码中千万别这么写，下面我们看正确的写法。
正确写法
在使用fastjson时，可以借助TypeReference完成指定泛型的反序列化：
public class TypeRefTest { public static void main(String[] args) { String jsonStr = "{\"obj\":{\"name\":\"Hydra\",\"age\":\"18\"},\"val\":\"str\"}"; Foo foo2 = JSONObject.parseObject(jsonStr, new TypeReference<Foo<User>>(){}); System.out.println(foo2.toString()); System.out.println(foo2.getObj().getClass()); }}
复制代码
运行结果：
Foo(val=str, obj=User(name=Hydra, age=18))class com.hydra.json.model.User
复制代码
Foo中的obj类型为User，符合我们的预期。下面我们就看看，fastjson是如何借助TypeReference完成的泛型类型擦除后的还原。
TypeReference
回头再看一眼上面的代码中的这句：
Foo foo2 = JSONObject.parseObject(jsonStr, new TypeReference<Foo<User>>(){});
复制代码
重点是parseObject方法中的第二个参数，注意在TypeReference<Foo<User>>()有一对大括号{}。也就是说这里创建了一个继承了TypeReference的匿名类的对象，在编译完成后的项目target目录下，可以找到一个TypeRefTest$1.class字节码文件，因为匿名类的命名规则就是主类名+$+(1,2,3……)。
反编译这个文件可以看到这个继承了TypeReference的子类：
static class TypeRefTest$1 extends TypeReference{ TypeRefTest$1() { }}
复制代码
我们知道，在创建子类的对象时，子类会默认先调用父类的无参构造方法，所以看一下TypeReference的构造方法：
protected TypeReference(){ Type superClass = getClass().getGenericSuperclass(); Type type = ((ParameterizedType) superClass).getActualTypeArguments()[0];
Type cachedType = classTypeCache.get(type); if (cachedType == null) { classTypeCache.putIfAbsent(type, type); cachedType = classTypeCache.get(type); } this.type = cachedType;}
复制代码
其实重点也就是前两行代码，先看第一行：
Type superClass = getClass().getGenericSuperclass();
复制代码
虽然这里是在父类中执行的代码，但是getClass()得到的一定是子类的 Class 对象，因为getClass()方法获取到的是当前运行的实例自身的 Class，不会因为调用位置改变，所以getClass()得到的一定是TypeRefTest$1。
获取当前对象的 Class 后，再执行了getGenericSuperclass()方法，这个方法与getSuperclass类似，都会返回直接继承的父类。不同的是getSuperclas没有返回泛型参数，而getGenericSuperclass则返回了包含了泛型参数的父类。
再看第二行代码：
Type type = ((ParameterizedType) superClass).getActualTypeArguments()[0];
复制代码
首先将上一步获得的Type强制类型转换为ParameterizedType参数化类型，它是泛型的一个接口，实例则是继承了它的ParameterizedTypeImpl类的对象。
在ParameterizedType中定义了三个方法，上面代码中调用的getActualTypeArguments()方法就用来返回泛型类型的数组，可能返回有多个泛型，这里的[0]就是取出了数组中的第一个元素。
验证
好了，明白了上面的代码的作用后，让我们通过 debug 来验证一下上面的过程，执行上面TypeRefTest的代码，查看断点中的数据：
这里发现一点问题，按照我们上面的分析，讲道理这里父类TypeReference的泛型应该是Foo<User>啊，为什么会出现一个List<String>？
别着急，让我们接着往下看，如果你在TypeReference的无参构造方法中加了断点，就会发现代码执行中会再调用一次这个构造方法。
好了，这次的结果和我们的预期相同，父类的泛型数组中存储了Foo<User>，也就是说其实TypeRefTest$1继承的父类，完成的来说应该是TypeReference<Foo<User>>，但是我们上面反编译的文件中因为擦除的原因没有显示。
那么还有一个问题，为什么这个构造方法会被调用了两次呢？
看完了TypeReference的代码，终于在代码的最后一行让我发现了原因，原来是在这里先创建了一个TypeReference匿名类对象！
public final static Type LIST_STRING = new TypeReference<List<String>>() {}.getType();
复制代码
因此整段代码执行的顺序是这样的：
至于在这里声明的LIST_STRING，在其他地方也没有被再使用过，Hydra 也不知道这行代码的意义是什么，有明白的小伙伴可以在后台留言告诉我。
这里在拿到了Foo中的泛型User后，后面就可以按照这个类型来反序列化了，对后续流程有兴趣的小伙伴可以自己去啃啃源码，这里就不展开了。
扩展
了解了上面的过程后，我们最后通过一个例子加深一下理解，以常用的HashMap作为例子：
public static void main(String[] args) { HashMap<String,Integer> map=new HashMap<String,Integer>(); System.out.println(map.getClass().getSuperclass()); System.out.println(map.getClass().getGenericSuperclass()); Type[] types = ((ParameterizedType) map.getClass().getGenericSuperclass()) .getActualTypeArguments(); for (Type t : types) { System.out.println(t); }}
复制代码
执行结果如下，可以看到这里取到的父类是HashMap的父类AbstractMap，并且取不到实际的泛型类型。
class java.util.AbstractMapjava.util.AbstractMap<K, V>KV
复制代码
修改上面的代码，仅做一点小改动：
public static void main(String[] args) { HashMap<String,Integer> map=new HashMap<String,Integer>(){}; System.out.println(map.getClass().getSuperclass()); System.out.println(map.getClass().getGenericSuperclass()); Type[] types = ((ParameterizedType) map.getClass().getGenericSuperclass()) .getActualTypeArguments(); for (Type t : types) { System.out.println(t); }}
复制代码
执行结果大有不同，可以看到，只是在new HashMap<String,Integer>()的后面加了一对大括号{}，就可以取到泛型的类型了：
class java.util.HashMapjava.util.HashMap<java.lang.String, java.lang.Integer>class java.lang.Stringclass java.lang.Integer
复制代码
因为这里实例化的是一个继承了HashMap的匿名内部类的对象，因此取到的父类就是HashMap，并可以获取到父类的泛型类型。
其实也可以再换一个写法，把这个匿名内部类换成显示声明的非匿名的内部类，再修改一下上面的代码：
public class MapTest3 { static class MyMap extends HashMap<String,Integer>{}
public static void main(String[] args) { MyMap myMap=new MyMap(); System.out.println(myMap.getClass().getSuperclass()); System.out.println(myMap.getClass().getGenericSuperclass()); Type[] types = ((ParameterizedType) myMap.getClass().getGenericSuperclass()) .getActualTypeArguments(); for (Type t : types) { System.out.println(t); } }}
复制代码
运行结果与上面完全相同：
class java.util.HashMapjava.util.HashMap<java.lang.String, java.lang.Integer>class java.lang.Stringclass java.lang.Integer
复制代码
唯一不同的是显式生成的内部类与匿名类命名规则不同，这里生成的字节码文件不是MapTest3$1.class，而是MapTest3$MyMap.class，在$符后面使用的是我们定义的类名。
好啦，那么这次的填坑之旅就到这里，我是 Hydra，下期见。
作者简介，码农参上，一个热爱分享的公众号，有趣、深入、直接，与你聊聊技术。欢迎添加好友，进一步交流。
评论