首先，Java有泛型这一个概念，初衷是为了保证在运行时出现的错误能提早放到编译时检查。
1）Java泛型
开发人员在使用泛型的时候，很容易根据自己的直觉而犯一些错误。比如一个方法如果接收List
2）实现方式：类型擦除
Java中的泛型基本上都是在编译器这个层次来实现的，在生成的Java字节代码中是不包含泛型中的类型信息的。
使用泛型的时候加上的类型参数，会被编译器在编译的时候去掉，这个过程就称为类型擦除。
如在代码中定义的List
很多泛型的奇怪特性都与这个类型擦除的存在有关，包括：
泛型类并没有自己独有的Class类对象。比如并不存在List
.class或是List .class，而只有List.class。 静态变量是被泛型类的所有实例所共享的。对于声明为MyClass
的类，访问其中的静态变量的方法仍然是 MyClass.myStaticVar。不管是通过new MyClass 还是new MyClass 创建的对象，都是共享一个静态变量。 泛型的类型参数不能用在Java异常处理的catch语句中。因为异常处理是由JVM在运行时刻来进行的。由于类型信息被擦除，JVM是无法区分两个异常类型MyException
和MyException 的。对于JVM来说，它们都是 MyException类型的。也就无法执行与异常对应的catch语句。
类型擦除的基本过程也比较简单，首先是找到用来替换类型参数的具体类。这个具体类一般是Object。如果指定了类型参数的上界的话，则使用这个上界。把代码中的类型参数都替换成具体的类。同时去掉出现的类型声明，即去掉<>的内容。比如T get()方法声明就变成了Object get()；List
class MyString implements Comparable {
public int compareTo(String str) {
return 0;
}
}
当类型信息被擦除之后，上述类的声明变成了
class MyString implements Comparable
但是这样的话，类MyString就会有编译错误，因为没有实现接口Comparable声明的int compareTo(Object)方法。这个时候就由编译器来动态生成这个方法。
3）泛型的检测：不符合泛型T的检测
在进行编译之前就对所有泛型进行检测，加入类型检测和转换的指令，比如返回泛型的结果实际上返回的是擦出后的类型，而虚拟机会多加一个类型转换的指令。
4）需要泛型之间的类型转换怎么做？通配符？与PECS
如果你是想遍历collection，并对每一项元素操作时，此时这个集合时生产者（生产元素），应该使用 Collection，因为相对于你泛型E，能放进E中的（把Collection中的元素放入E类型中） ，应该是E的子类型。
如果你是想添加元素到collection中去，那么此时集合时消费者（消费元素）应该使用Collection，同理，你要将E类的元素放入Collection中去，那么Collection应该存放的是E的父类型。
5）泛型与多态的冲突
现在有这样一个泛型类：
class Pair {
private T value;
public T getValue() {
return value;
}
public void setValue(T value) {
this.value = value;
}
}
然后我们想要一个子类继承它
class DateInter extends Pair {
@Override
public void setValue(Date value) {
super.setValue(value);
}
@Override
public Date getValue() {
return super.getValue();
}
在这个子类中，我们设定父类的泛型类型为Pair
将父类的泛型类型限定为Date，那么父类里面的两个方法的参数都为Date类型：
public Date getValue() {
return value;
}
public void setValue(Date value) {
this.value = value;
}
所以，我们在子类中重写这两个方法一点问题也没有，实际上，从他们的@Override标签中也可以看到，一点问题也没有，实际上是这样的吗？
分析：
实际上，类型擦除后，父类的的泛型类型全部变为了原始类型Object，所以父类编译之后会变成下面的样子：
class Pair {
private Object value;
public Object getValue() {
return value;
}
public void setValue(Object value) {
this.value = value;
}
}
再看子类的两个重写的方法的类型：
@Override
public void setValue(Date value) {
super.setValue(value);
}
@Override
public Date getValue() {
return super.getValue();
}
先来分析setValue方法，父类的类型是Object，而子类的类型是Date，参数类型不一样，这如果实在普通的继承关系中，根本就不会是重写，而是重载。
我们在一个main方法测试一下：
public static void main(String[] args) throws ClassNotFoundException {
DateInter dateInter=new DateInter();
dateInter.setValue(new Date());
dateInter.setValue(new Object());//编译错误
}
如果是重载，那么子类中两个setValue方法，一个是参数Object类型，一个是Date类型，可是我们发现，根本就没有这样的一个子类继承自父类的Object类型参数的方法。所以说，却是是重写了，而不是重载了。
为什么会这样呢？
原因是这样的，我们传入父类的泛型类型是Date，Pair
class Pair {
private Date value;
public Date getValue() {
return value;
}
public void setValue(Date value) {
this.value = value;
}
}
然后再子类中重写参数类型为Date的那两个方法，实现继承中的多态。
可是由于种种原因，虚拟机并不能将泛型类型变为Date，只能将类型擦除掉，变为原始类型Object。这样，我们的本意是进行重写，实现多态。可是类型擦除后，只能变为了重载。这样，类型擦除就和多态有了冲突。JVM知道你的本意吗？知道！！！可是它能直接实现吗，不能！！！如果真的不能的话，那我们怎么去重写我们想要的Date类型参数的方法啊。
于是JVM采用了一个特殊的方法，来完成这项功能，那就是桥方法。
首先，我们用javap -c className的方式反编译下DateInter子类的字节码，结果如下：
class com.tao.test.DateInter extends com.tao.test.Pair {
com.tao.test.DateInter();
Code:
0: aload_0
1: invokespecial #8 // Method com/tao/test/Pair.""
:()V
4: return
public void setValue(java.util.Date); //我们重写的setValue方法
Code:
0: aload_0
1: aload_1
2: invokespecial #16 // Method com/tao/test/Pair.setValue
:(Ljava/lang/Object;)V
5: return
public java.util.Date getValue(); //我们重写的getValue方法
Code:
0: aload_0
1: invokespecial #23 // Method com/tao/test/Pair.getValue
:()Ljava/lang/Object;
4: checkcast #26 // class java/util/Date
7: areturn
public java.lang.Object getValue(); //编译时由编译器生成的巧方法
Code:
0: aload_0
1: invokevirtual #28 // Method getValue:()Ljava/util/Date 去调用我们重写的getValue方法
;
4: areturn
public void setValue(java.lang.Object); //编译时由编译器生成的巧方法
Code:
0: aload_0
1: aload_1
2: checkcast #26 // class java/util/Date
5: invokevirtual #30 // Method setValue:(Ljava/util/Date; 去调用我们重写的setValue方法
)V
8: return
}
从编译的结果来看，我们本意重写setValue和getValue方法的子类，竟然有4个方法，其实不用惊奇，最后的两个方法，就是编译器自己生成的桥方法。可以看到桥方法的参数类型都是Object，也就是说，子类中真正覆盖父类两个方法的就是这两个我们看不到的桥方法。而打在我们自己定义的setvalue和getValue方法上面的@Oveerride只不过是假象。而桥方法的内部实现，就只是去调用我们自己重写的那两个方法。
所以，虚拟机巧妙的使用了巧方法，来解决了类型擦除和多态的冲突。
不过，要提到一点，这里面的setValue和getValue这两个桥方法的意义又有不同。
setValue方法是为了解决类型擦除与多态之间的冲突。
而getValue却有普遍的意义，怎么说呢，如果这是一个普通的继承关系：
那么父类的setValue方法如下：
public Object getValue() {
return super.getValue();
}
而子类重写的方法是：
public Date getValue() {
return super.getValue();
}
其实这在普通的类继承中也是普遍存在的重写，这就是协变。
关于协变：。。。。。。
并且，还有一点也许会有疑问，子类中的巧方法 Object getValue()和Date getValue()是同 时存在的，可是如果是常规的两个方法，他们的方法签名是一样的，也就是说虚拟机根本不能分别这两个方法。如果是我们自己编写Java代码，这样的代码是无法通过编译器的检查的，但是虚拟机却是允许这样做的，因为虚拟机通过参数类型和返回类型来确定一个方法，所以编译器为了实现泛型的多态允许自己做这个看起来“不合法”的事情，然后交给虚拟器去区别。