JDK源码剖析网：http://hotspotvm.cn
泛型存在于Java源代码中，在编译为字节码文件之前都会进行泛型擦除（type erasure），因此，Java的泛型完全由Javac等编译器在编译期提供支持，可以理解为Java的一颗语法糖，这种方式实现的泛型有时也称为“伪泛型”。
泛型擦除本质上就是擦除与泛型相关的一切信息，例如参数化类型、类型变量等，Javac还将在需要时进行类型检查及强制类型转换，甚至在必要时会合成桥方法。
1、真假泛型
如果你是Java业务开发者，其实这种所谓的伪泛型已经达到了方便使用的目的，例如在容器的使用过程中，能够记住其类型，这样就不用在获取时专门做强制类型转换了，如下：
泛型尤其在我们使用容器类，如ArrayList、 HashMap等时能提供便利。
假设Java不支持泛型，那么我们针对Integer类型进行封装的Wrapper代码应该是如下的样子：
这个Wrapper明显是只能对int类型进行封装，不过其实现和之前比起来要简洁，不但实例字段内存占用减少，还没有了装箱和拆箱操作，也省去了强制类型转换。这也是我们在使用Java泛型时希望看到的版本。
以目前Java的实现来看，是对泛型进行擦除处理的，对Wrapper<Integer>类型进行擦除后的代码如下所示。
由于在整个应用中，无论是Wrapper<Integer>还是Wrapper<String>这些类型来说，其Wrapper在虚拟机中只有一个版本，因为需要对任何的Java对象进行封装，所以声明为Object，当然如果你知道只会放某个更具体的类或这个类的子类时，也可以将Wrapper类型声明的更精确一些，如Wrapper<T extends Serializable>。
假设像C++的模板类一样，Java的“真泛型”也为每一个具体的泛型生成一个独有的类（类型膨胀式泛型），那么就如下图所示。
可以看到，真泛型会针对具体的类型生成独有的类型。针对Wrapper<Integer>就应该有是这样：
这次类型非常精确，也没有了强制类型转换。不过与我们理想中的还有差距，主要是没有将Wrapper中的类型声明为基本类型int，这会导致装箱和拆箱操作。在Java中，装箱和拆箱操作很频繁，为此JDK开发人员也在努力优化，如延迟装箱等，现在，Project Valhalla要让泛型能支持原始类型。好在除非是专门做优化的人，否则一般开发者也不会注意到这种装箱和拆箱的开销。
这里还要说的是，由于对象和基本类型找不到一个共同的父类，所以在泛型擦除时只能是对象类型，也就是说，我们不能在Java中写一个类似Wrapper<int>这样的声明。这篇文章我们暂时不讨论这个问题，我们讨论另外一个重要的问题，也就是为任何一个泛型生成一个真正的类与这种伪泛型的擦除之间会造成哪些性能影响？
2、性能影响
我们举几个小例子来看一下：
实例1
我们自定义了一个对Integer类封装的Wrapper1类，这个类在泛型擦除后如下所示。
在泛型擦除后，Wrapper类的setData()方法的类型变量T被替换为Object类型，这样SpecWrapper类中的setData(Integer data)并没有覆写这个方法，所以为了覆写特性，向SpecWrapper类中添加一个合成的桥方法setData(Objext x0)。
这会让我们在实际调用setData()方法时调用的是setData(Object x0)方法，这个方法又调用了setData(Integer data)方法，而在“真泛型”中，我们直接调用setData(Integer data)方法即可，虽然JIT会大概率对这种简单的方法进行内联，但是性能影响肯定是有的。
实例2
我们关注一下test()方法中的t.invoke()动态分派，通过泛型擦除之后，TestGeneric类中的T是Parent类型，那么test()方法中t声明的类型就是Parent，如下：
配置如下命令查看C2编译的结果：
XX:CompileCommand=compileonly,cn/hotspotvm/TestGeneric::test -XX:CompileCommand=print,cn/hotspotvm/TestGeneric::test
C2编译的版本出来如下：
也就等同于如下：
if(t是Sub1类型){
直接调用Sub1的invoke()方法，也就
是optimized virtual_call的意思
}else{
动态分派，通过查找方法表来实现调用，
也就是invokevirtual invoke的意思
}C2实际是通过运行时采样，发现t的类型只有Sub1，所以做了这样的优化，将动态分派优化为了一次比较+一次直接调用的开销。
假设是“真泛型”上场，那TestGeneric应该是如下的样子：
此时C2编译出来的版本如下：
直接就是直调，比之前省了一次判断，代码很简洁。因为C2得到了t的更精确类型Sub1，并且这个Sub1还是final修饰的类，不会有子类，所以直接调用即可。
虽然少量调用可能并不能体现出来差异，更何况现在的C2优化实在强大，使得它们的性能差异可能只在极少数的情况下才能体现出来。
C2编译器非常喜欢精确类型，这样在类型传播的过程中能触发许多优化，编译出性能更好的版本，后续我们在介绍C2时，看一看其类型传播，就能深刻体会到它的强大。
实例3
假设有这么一个方法，实现如下：
对于伪泛型来说，擦除后，T是Parent类型。方法test(Parent t)无法做任何优化。
对于真泛型来说，至少Wrapper<Sub1>和Wrapper<Sub2>版本中的test()是可以优化的。
public void test(Sub1 t)版本中只需要直接执行Sub1的逻辑就可以，并不需要判断，因为Sub1是final类，所以t只能是Sub1类型，如下：
public void test(Sub1 t){
执行Sub1的逻辑
}public void test(Sub2 t)版本中只需要直接执行Sub2的逻辑就可以，并不需要判断，虽然Sub2是非final类型，但是经过类层次分析后发现，Sub2没有具体的实现子类，那这时候也能认为这个版本只有Sub2类型。
public void test(Sub2 t){
执行Sub2的逻辑
}如果你想了解下Java为啥不支持这种类型的泛型，可以参考 R大在知乎的回答
https://www.zhihu.com/question/54347051/answer/151734382，简单来说，就是为了高版本的兼容性做了一种妥协的策略而已。