Java泛型详解(内附代码示例)，零基础小白到精通，收藏这篇就够了-平芜编程栈

概念

概念移步百度百科:java泛型
我只说一下我的理解，使用数据类型约束主要是为了安全性，这样可以在编译期发现更多的风险，并且减少代码强转。在使用的时候定义好数据类型，也算是一种约束，对内部的代码调用等都非常的友好。
java中可以定义指定的数据类型，也可以定义泛型，当定义了指定的数据类型时，它就仅能接收这一种数据类型，所以有时候我们为了使一个类或者接口或者方法面相更多的对象时不那么乏力，这个时候我们的泛型就登场了。
举个栗子来比较一下数据类型和泛型

明显我们可以看出泛型适用于一些灵活的场景，比如excel导入导出我们不确定数据类型；比如jdbc封装时我们不确定的数据类型；比如一些特殊场景需要用一个类或者一个方法或者一个接口面向多种数据类型编码时。

泛型的擦除

什么叫泛型的擦除，我们来看一个栗子

这里定义了两个不同数据类型的集合，一个String，另一个是Integer，获取两个集合的class进行对比，最终结果是一致的。这里是由于泛型的特性:泛型仅在编译时有效，简单的说就是会在编译时期检查你的泛型，但是运行时期就已经把类型擦除，两个list都变成了没有数据类型的工具，相当于:

List stringArrayList = Lists.newArrayList();

如此一来就运行时就出现了上述结果，两个带有数据类型约束的类比较结果竟然是true。

泛型的类型

泛型的类型主要有三种，泛型类、泛型接口、泛型方法。下面我们一一道来。

1.泛型类

泛型类的最基本写法

class 类名称 <泛型标识：可以随便写任意标识号，标识指定的泛型的类型>{ private 泛型标识 /*（成员变量类型）*/ var; ..... } }

举个栗子

使用时需要注意的是:泛型的类型参数不能是简单类型，否则编译会报错Type argument cannot be of primitive type;定义泛型类的时候可以不用传入类型实参。

2.泛型接口

泛型接口与泛型类的定义及使用基本相同。泛型接口常被用在各种类的生产器中，可以看一个例子:

public interface TestInterface<T> { public T getNext(); }

当实现泛型接口的类，未传入泛型实参时：

/** * 未传入泛型实参时，与泛型类的定义相同，在声明类的时候，需将泛型的声明也一起加到类中 * 即：class FruitGenerator<T> implements Generator<T>{ * 如果不声明泛型，如：class FruitGenerator implements Generator<T>，编译器会报错："Unknown class" */ class FruitGenerator<T> implements Generator<T>{ @Override public T next() { return null; } }

当实现泛型接口的类，传入泛型实参时：

/** * 传入泛型实参时： * 定义一个生产器实现这个接口,虽然我们只创建了一个泛型接口Generator<T> * 但是我们可以为T传入无数个实参，形成无数种类型的Generator接口。 * 在实现类实现泛型接口时，如已将泛型类型传入实参类型，则所有使用泛型的地方都要替换成传入的实参类型 * 即：Generator<T>，public T next();中的的T都要替换成传入的String类型。 */ public class FruitGenerator implements Generator<String> { private String[] fruits = new String[]{"Apple", "Banana", "Pear"}; @Override public String next() { Random rand = new Random(); return fruits[rand.nextInt(3)]; } }

3.泛型通配符

我们知道Ingeter是Number的一个子类，同时在特性章节中我们也验证过Generic<Ingeter>与Generic<Number>实际上是相同的一种基本类型。那么问题来了，在使用Generic<Number>作为形参的方法中，能否使用Generic<Ingeter>的实例传入呢？在逻辑上类似于Generic<Number>和Generic<Ingeter>是否可以看成具有父子关系的泛型类型呢？

为了弄清楚这个问题，我们使用Generic<T>这个泛型类继续看下面的例子：

public void showKeyValue1(Generic<Number> obj){ Log.d("泛型测试","key value is " + obj.getKey()); } Generic<Integer> gInteger = new Generic<Integer>(123); Generic<Number> gNumber = new Generic<Number>(456); showKeyValue(gNumber); // showKeyValue这个方法编译器会为我们报错：Generic<java.lang.Integer> // cannot be applied to Generic<java.lang.Number> // showKeyValue(gInteger);

通过提示信息我们可以看到Generic<Integer>不能被看作为Generic<Number>的子类。由此可以看出:同一种泛型可以对应多个版本（因为参数类型是不确定的），不同版本的泛型类实例是不兼容的。

回到上面的例子，如何解决上面的问题？总不能为了定义一个新的方法来处理Generic<Integer>类型的类，这显然与java中的多台理念相违背。因此我们需要一个在逻辑上可以表示同时是Generic<Integer>和Generic<Number>父类的引用类型。由此类型通配符应运而生。

我们可以将上面的方法改一下：

public void showKeyValue1(Generic<?> obj){ Log.d("泛型测试","key value is " + obj.getKey()); }

类型通配符一般是使用？代替具体的类型实参，注意了，此处’？’是类型实参，而不是类型形参。重要说三遍！此处’？’是类型实参，而不是类型形参！此处’？’是类型实参，而不是类型形参！再直白点的意思就是，此处的？和Number、String、Integer一样都是一种实际的类型，可以把？看成所有类型的父类。是一种真实的类型。

可以解决当具体类型不确定的时候，这个通配符就是 ? ；当操作类型时，不需要使用类型的具体功能时，只使用Object类中的功能。那么可以用 ? 通配符来表未知类型。

4.泛型方法

在java中,泛型类的定义非常简单，但是泛型方法就比较复杂了

尤其是我们见到的大多数泛型类中的成员方法也都使用了泛型，有的甚至泛型类中也包含着泛型方法，这样在初学者中非常容易将泛型方法理解错了。
泛型类，是在实例化类的时候指明泛型的具体类型；泛型方法，是在调用方法的时候指明泛型的具体类型。

注释里面标明了一个泛型方法应该怎样定义。

/** * 泛型方法的基本介绍 * @param tClass 传入的泛型实参 * @return T 返回值为T类型 * 说明： * 1）public 与 返回值中间<T>非常重要，可以理解为声明此方法为泛型方法。 * 2）只有声明了<T>的方法才是泛型方法，泛型类中的使用了泛型的成员方法并不是泛型方法。 * 3）<T>表明该方法将使用泛型类型T，此时才可以在方法中使用泛型类型T。 * 4）与泛型类的定义一样，此处T可以随便写为任意标识，常见的如T、E、K、V等形式的参数常用于表示泛型。 */ public <T> T genericMethod(Class<T> tClass)throws InstantiationException , IllegalAccessException{ T instance = tClass.newInstance(); return instance; }

1.泛型方法的基本用法

举几个栗子，大家可以参照代码中的注释进行理解

public class GenericTest { //这个类是个泛型类，在上面已经介绍过 public class Generic<T>{ private T key; public Generic(T key) { this.key = key; } //我想说的其实是这个，虽然在方法中使用了泛型，但是这并不是一个泛型方法。 //这只是类中一个普通的成员方法，只不过他的返回值是在声明泛型类已经声明过的泛型。 //所以在这个方法中才可以继续使用 T 这个泛型。 public T getKey(){ return key; } /** * 这个方法显然是有问题的，在编译器会给我们提示这样的错误信息"cannot reslove symbol E" * 因为在类的声明中并未声明泛型E，所以在使用E做形参和返回值类型时，编译器会无法识别。 public E setKey(E key){ this.key = keu } */ } /** * 这才是一个真正的泛型方法。 * 首先在public与返回值之间的<T>必不可少，这表明这是一个泛型方法，并且声明了一个泛型T * 这个T可以出现在这个泛型方法的任意位置. * 泛型的数量也可以为任意多个 * 如：public <T,K> K showKeyName(Generic<T> container){ * ... * } */ public <T> T showKeyName(Generic<T> container){ System.out.println("container key :" + container.getKey()); //当然这个例子举的不太合适，只是为了说明泛型方法的特性。 T test = container.getKey(); return test; } //这也不是一个泛型方法，这就是一个普通的方法，只是使用了Generic<Number>这个泛型类做形参而已。 public void showKeyValue1(Generic<Number> obj){ Log.d("泛型测试","key value is " + obj.getKey()); } //这也不是一个泛型方法，这也是一个普通的方法，只不过使用了泛型通配符? //同时这也印证了泛型通配符章节所描述的，?是一种类型实参，可以看做为Number等所有类的父类 public void showKeyValue2(Generic<?> obj){ Log.d("泛型测试","key value is " + obj.getKey()); } /** * 这个方法是有问题的，编译器会为我们提示错误信息："UnKnown class 'E' " * 虽然我们声明了<T>,也表明了这是一个可以处理泛型的类型的泛型方法。 * 但是只声明了泛型类型T，并未声明泛型类型E，因此编译器并不知道该如何处理E这个类型。 public <T> T showKeyName(Generic<E> container){ ... } */ /** * 这个方法也是有问题的，编译器会为我们提示错误信息："UnKnown class 'T' " * 对于编译器来说T这个类型并未项目中声明过，因此编译也不知道该如何编译这个类。 * 所以这也不是一个正确的泛型方法声明。 public void showkey(T genericObj){ } */ public static void main(String[] args) { } }

2.类中的泛型方法

其实类中的方法和泛型方法我认为还是比较好区分的，在public/private等访问修饰符和返回值之间是否定义了泛型，如果定义了则就是一个泛型方法，仅供参考。

public class GenericFruit { class Fruit{ @Override public String toString() { return "fruit"; } } class Apple extends Fruit{ @Override public String toString() { return "apple"; } } class Person{ @Override public String toString() { return "Person"; } } class GenerateTest<T>{ public void show_1(T t){ System.out.println(t.toString()); } //在泛型类中声明了一个泛型方法，使用泛型E，这种泛型E可以为任意类型。可以类型与T相同，也可以不同。 //由于泛型方法在声明的时候会声明泛型<E>，因此即使在泛型类中并未声明泛型，编译器也能够正确识别泛型方法中识别的泛型。 public <E> void show_3(E t){ System.out.println(t.toString()); } //在泛型类中声明了一个泛型方法，使用泛型T，注意这个T是一种全新的类型，可以与泛型类中声明的T不是同一种类型。 public <T> void show_2(T t){ System.out.println(t.toString()); } } public static void main(String[] args) { Apple apple = new Apple(); Person person = new Person(); GenerateTest<Fruit> generateTest = new GenerateTest<Fruit>(); //apple是Fruit的子类，所以这里可以 generateTest.show_1(apple); //编译器会报错，因为泛型类型实参指定的是Fruit，而传入的实参类是Person //generateTest.show_1(person); //使用这两个方法都可以成功 generateTest.show_2(apple); generateTest.show_2(person); //使用这两个方法也都可以成功 generateTest.show_3(apple); generateTest.show_3(person); } }

3.泛型方法与可变参数

public <T> void printMsg( T... args){ for(T t : args){ Log.d("泛型测试","t is " + t); } } //printMsg("111",222,"aaaa","2323.4",55.55);

4.静态方法与泛型

静态方法有一种情况需要注意一下，那就是在类中的静态方法使用泛型：静态方法无法访问类上定义的泛型；如果静态方法操作的引用数据类型不确定的时候，必须要将泛型定义在方法上。

即：如果静态方法要使用泛型的话，必须将静态方法也定义成泛型方法。

public class StaticGenerator<T> { .... .... /** * 如果在类中定义使用泛型的静态方法，需要添加额外的泛型声明（将这个方法定义成泛型方法） * 即使静态方法要使用泛型类中已经声明过的泛型也不可以。 * 如：public static void show(T t){..},此时编译器会提示错误信息： "StaticGenerator cannot be refrenced from static context" */ public static <T> void show(T t){ } }

5.泛型方法总结

无论何时，如果你能做到，你就该尽量使用泛型方法。也就是说，如果使用泛型方法将整个类泛型化， 那么就应该使用泛型方法。另外对于一个static的方法而已，无法访问泛型类型的参数。 所以如果static方法要使用泛型能力，就必须使其成为泛型方法。

5.泛型上下边界

在使用泛型的时候，我们还可以为传入的泛型类型实参进行上下边界的限制，如：类型实参只准传入某种类型的父类或某种类型的子类。
为泛型添加上边界，即传入的类型实参必须是指定类型的子类型

public void showKeyValue1(Generic<? extends Number> obj){ Log.d("泛型测试","key value is " + obj.getKey()); } Generic<String> generic1 = new Generic<String>("11111"); Generic<Integer> generic2 = new Generic<Integer>(2222); Generic<Float> generic3 = new Generic<Float>(2.4f); Generic<Double> generic4 = new Generic<Double>(2.56); //这一行代码编译器会提示错误，因为String类型并不是Number类型的子类 //showKeyValue1(generic1); showKeyValue1(generic2); showKeyValue1(generic3); showKeyValue1(generic4);

我们把泛型类的定义也改一下:

public class Generic<T extends Number>{ private T key; public Generic(T key) { this.key = key; } public T getKey(){ return key; } } //这一行代码也会报错，因为String不是Number的子类 Generic<String> generic1 = new Generic<String>("11111");

再来一个泛型方法的例子：

//在泛型方法中添加上下边界限制的时候，必须在权限声明与返回值之间的<T>上添加上下边界，即在泛型声明的时候添加 //public <T> T showKeyName(Generic<T extends Number> container)，编译器会报错："Unexpected bound" public <T extends Number> T showKeyName(Generic<T> container){ System.out.println("container key :" + container.getKey()); T test = container.getKey(); return test; }

通过上面的两个例子可以看出：泛型的上下边界添加，必须与泛型的声明在一起。

文章借鉴了很多其他文章的demo，也有一些自己手撸的代码，供大家参考。

Java程序员如今深陷技术迭代放缓与行业需求收缩的双重困境，职业发展空间正被新兴技术浪潮持续挤压。面对当前Java程序员可能面临的“发展瓶颈”或行业挑战，更积极的应对策略可以围绕技术升级、方向转型、能力拓展三个核心展开，而非被动接受“不行”的标签，通过调查对比，我发现人工智能大模型是个很好的出路。