<和有什么区别？扩展Base>和<T扩展Base>？

在此示例中：

import java.util.*;

public class Example {
    static void doesntCompile(Map<Integer, List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    static void function(List<? extends Number> outer)
    {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

doesntCompile() 无法编译为：

Example.java:9: error: incompatible types: HashMap<Integer,List<Integer>> cannot be converted to Map<Integer,List<? extends Number>>
        doesntCompile(new HashMap<Integer, List<Integer>>());
                      ^

而compiles()被编译器接受。

该答案说明，唯一的区别是与不同<? ...>，它<T ...>允许您稍后引用类型，似乎并非如此。

是什么区别<? extends Number>，并<T extends Number>在这种情况下，为什么不第一编译？

通过使用以下签名定义方法：

static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

并像这样调用它：

compiles(new HashMap<Integer, List<Integer>>());

在jls§8.1.2中，我们发现（有趣的部分被我加粗了）：

通用类声明定义了一组参数化类型（第4.5节），每种可能通过类型arguments调用类型参数节的类型。所有这些参数化类型在运行时共享同一类。

换句话说，将类型T与输入类型进行匹配并进行分配Integer。签名将有效地变为static void compiles(Map<Integer, List<Integer>> map)。

关于doesntCompile方法，jls定义了子类型化规则（第4.5.1节，由我加粗）：

如果在以下规则的自反和传递闭包中，证明T2表示的类型集是T1表示的类型集的子集，则类型自变量T1包含另一个类型自变量T2，写为T2 <= T1。其中<：表示子类型（§4.10））：

• ？扩展T <=？如果T <：S则扩展S

• ？扩展T <=？

• ？超级T <=？如果S <：T则为超级S

• ？超级T <=？

• ？超级T <=？扩展对象

• T <= T

• T <=？延伸T

• T <=？超级T

这意味着，? extends Number确实包含Integer甚至List<? extends Number>包含List<Integer>，但Map<Integer, List<? extends Number>>and 并非如此Map<Integer, List<Integer>>。在该SO线程中可以找到关于该主题的更多信息。您仍然可以?通过声明期望使用以下子类型来使带有通配符的版本起作用List<? extends Number>：

public class Example {
    // now it compiles
    static void doesntCompile(Map<Integer, ? extends List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    public static void main(String[] args) {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

在通话中：

compiles(new HashMap<Integer, List<Integer>>());

T与Integer匹配，因此参数的类型为Map<Integer,List<Integer>>。方法不是这样doesntCompile：参数的类型保持不变Map<Integer, List<? extends Number>>无论调用中的实际参数如何，参数。并且不能从分配HashMap<Integer, List<Integer>>。

更新

在该doesntCompile方法中，没有什么可以阻止您执行以下操作：

static void doesntCompile(Map<Integer, List<? extends Number>> map) {
    map.put(1, new ArrayList<Double>());
}

很明显，它不能接受a HashMap<Integer, List<Integer>>作为参数。

演示的简化示例。相同的示例可以如下所示。

static void demo(List<Pair<? extends Number>> lst) {} // doesn't work
static void demo(List<? extends Pair<? extends Number>> lst) {} // works
demo(new ArrayList<Pair<Integer>()); // works
demo(new ArrayList<SubPair<Integer>()); // works for subtype too

public static class Pair<T> {}
public static class SubPair<T> extends Pair<T> {}

List<Pair<? extends Number>>是多级通配符类型，List<? extends Number>而是标准通配符类型。

通配符类型的有效具体实例List<? extends Number>包括Number和的任何子类型，Number而在这种情况下List<Pair<? extends Number>>，则是类型实参的类型实参，并且自身具有泛型的具体实例。

泛型是不变的，因此Pair<? extends Number>通配符类型只能接受Pair<? extends Number>>。内部类型? extends Number已经是协变的。您必须将封闭类型设为协变以允许协变。

我建议您查看通用通配符的文档，尤其是通配符使用准则

坦白地说，您的方法#doesntCompile

static void doesntCompile(Map<Integer, List<? extends Number>> map) {}

并像

doesntCompile(new HashMap<Integer, List<Integer>>());

根本上是不正确的

让我们添加法律实施：

    static void doesntCompile(Map<Integer, List<? extends Number>> map) {
        List<Double> list = new ArrayList<>();
        list.add(0.);
        map.put(0, list);
    }

真的很好，因为Double扩展了Number，所以put List<Double>也绝对好List<Integer>，对吗？

但是，您仍然认为从您的示例中通过此处是合法的new HashMap<Integer, List<Integer>>()吗？

编译器不这么认为，并且正在尽最大努力避免这种情况。

尝试使用#compile方法执行相同的实现，并且显然编译器将不允许您将double列表放入map中。

    static <T extends Number> void compiles(Map<Integer, List<T>> map) {
        List<Double> list = new ArrayList<>();
        list.add(10.);
        map.put(10, list); // does not compile
    }

基本上您什么也不能放，但这List<T>就是为什么使用new HashMap<Integer, List<Integer>>()or new HashMap<Integer, List<Double>>()或new HashMap<Integer, List<Long>>()or 调用该方法是安全的new HashMap<Integer, List<Number>>()。

简而言之，您正在尝试使用编译器作弊，并且它相当防御这种作弊。

注意：莫里斯·佩里（Maurice Perry）发表的答案是绝对正确的。我只是不确定它是否足够清晰，因此尝试（真的希望我设法）增加了更多文章。