看到有同学问的这样一个问题,也引发了我的思考

于是查了查网上的帖子,发现,不是所有泛型都有所谓的泛型擦除效果的。
https://www.zhihu.com/question/346911525/answer/830285753?utm_source=wechat_session&utm_medium=social&utm_oi=661648077853822976&utm_content=sec
这个帖子就举例了,
可以通过反射获取到的泛型信息一定是某个class作为成员变量、方法返回值等位置的具体泛型类型,举例来说:
public class Test<T> {
private Test<Integer> test;
private T item;}
在上面的代码中,可以通过反射获取成员test的Integer泛型信息,但是无法获取成员item的实际类型。
帖子中作者追溯到JDK8的源码,发现例子中的test成员编译时会将Integer信息编译进class字节码,从而反射系统就可以获取到这个信息,
也就说在类加载阶段,JVM就将字节码中写死的泛型信息保存了下来。而反射的时候,反射系统自然就可以获取到该信息,从而可以通过getGenericType()来获取到Type信息,从而解析出泛型类型。
而如同例子中定义的item这类泛型引用来说,它们的泛型信息不来自于自身的class,在编译完成通过类型检查后,类型系统中它们就等同于Object,这种泛型是无法通过反射获取的,也就是说这类类型信息被擦除了。
所以真正擦除的应该是例子中的T这类在源代码当中没有具体指定的泛型,才是反射无法获取到的。
看了另一篇帖子,作者给出以下的见解:
java中的泛型在jdk1.5之后才加进去的,功能基本都是模仿c++中泛型,但是没有c++的泛型那样强大到可在程序执行时都还有泛型功能.这是跟起初java的虚拟机JVM的设计有关,如果要将泛型功能全部添加到JVM中也可以,但是工程量非常大,sun公司不会因为一个泛型的追求而去几乎翻新一个JVM.所以就放弃了.
但是泛型在java中还是有一定的作用的,所以sun公司就在编译器中实现了一个可以擦出泛型的方法.
这么一来java中泛型的生命周期就只能在源代码到编译期了.这就为什么会出现在字节码中可以获取到泛型的Type对象,而又可以绕过泛型对参数化了的集合进行其他数据类型存储的现象.
那为什么sun公司还要提供我们在字节码中获取到泛型的Type对象呢?
我想这是sun公司为了伱补java泛型的不完美吧!让我们在程序中可以手动实现一个方法去检测接受的数据类型是否就是源代码中定义的泛型类型,如果
不是那么就做相应处理.这样使得程序执行起来更安全,不会因为项目在部署后因传入其他数据类型而照成程序异常等结果发生.
自己的理解:这位作者的意思与上一个作者的相同,就是那些可以被反射读取到的泛型类型信息已经存在字节码文件当中了,但是sun公司不会因为一个泛型而翻新JVM,不想让泛型的功能太过于强大,不然太复杂了,于是它就在编译器中实现了一个可以擦除泛型的方法,让大家认为,【字节码文件当中没有储存泛型的信息,“泛型被擦除了”】,
让大家停止使用泛型的进一步强大的功能,因为没有提供。
这就是为什么反射可以绕过泛型对参数化了的集合进行其他数据类型存储,造成了泛型的生命周期只存在于源代码期间的感受。(就是视频中的第一个案例,使用反射向List<String> list 里面添加Integer类型的123,并且成功了,按理说正常情况下list.add(123)是不能成功添加的,但是反射成功添加了,所以感觉设置泛型好像没有用一样,我们的解释是因为泛型在编译后的字节码文件被"擦除了"。这个案例的结论是泛型的生命周期只存在源代码期间,编译后的字节码文件是没有出现泛型的,而反射是运行期间起作用,两者的生命周期不一样,所以反射操纵不了泛型,所以更不会想到去使用泛型的更强大的功能)。这也是jdk聪明的一点,它让大家认为,泛型信息被擦除了,让大家认为,泛型信息没有存在字节码文件当中。其生命周期在源代码阶段,止步于编译期间。
但是实际上呢,字节码文件当中确实是存储了那些在源代码当中的具体化了的泛型类的信息的,并且类加载阶段,JVM就将字节码中写死的泛型信息保存了下来,这也是为什么我们能够通过反射得到泛型的Type对象。
并且这个帖子的作者说:既然没有实现泛型的更强大的功能,那为什么还要给我们提供Type对象呢?可能是为了程序的安全性考虑,弥补java泛型的不完美,可以让我们在程序中手动实现一个方法去检测接收的数据类型是否就是源代码中定义的泛型类型。
以上纯属查资料的个人理解,仅供参考。。。