第一个签名说：list1是一个ES列表。

第二个签名说：list是某种类型的实例的List，但是我们不知道类型。

当我们尝试更改方法时，区别变得明显，因此它需要第二个参数，该参数应添加到方法内部的列表中：

import java.util.List;

public class Experiment {
    public static <E> void funct1(final List<E> list1, final E something) {
        list1.add(something);
    }

    public static void funct2(final List<?> list, final Object something) {
        list.add(something); // does not compile
    }
}

第一个效果很好。而且你不能将第二个参数更改为可以实际编译的任何参数。

实际上，我发现了一个更好的区别说明：

public class Experiment {
    public static <E> void funct1(final List<E> list) {
        list.add(list.get(0));
    }

    public static void funct2(final List<?> list) {
        list.add(list.get(0)); // !!!!!!!!!!!!!! won't compile !!!!!!!!!
    }
}

一个可能是为什么<?>当它仅限制我们可以使用它时（如@Babu_Reddy_H在注释中所做的那样），我们为什么需要它。我看到了通配符版本的以下好处：

调用者不必对传入的对象有所了解。例如，如果我有一个列表列表：Map<String, List<?>>我可以将其值传递给你的函数，而无需指定列表元素的类型。所以

如果我分发这样参数化的对象，则会积极地限制人们对这些对象的了解以及它们可以做什么（只要它们远离不安全的铸造）。

当我将它们结合在一起时，这两个是有意义的：List<? extends T>。例如，考虑一个method List<T> merge(List<? extends T>, List<? extends T>)，它将两个输入列表合并到一个新的结果列表中。当然可以引入另外两个类型参数，但是为什么要这么做呢？这将超过指定的东西。

最后，通配符可以有一个较低的界限，因此使用列表可以使该add方法起作用，而get对你却没有任何帮助。当然，这引发了下一个问题：为什么泛型没有下界？