（添加答案，因为使用泛型通配符的示例永远不够）

       // Source 
       List<Integer> intList = Arrays.asList(1,2,3);
       List<Double> doubleList = Arrays.asList(2.78,3.14);
       List<Number> numList = Arrays.asList(1,2,2.78,3.14,5);

       // Destination
       List<Integer> intList2 = new ArrayList<>();
       List<Double> doublesList2 = new ArrayList<>();
       List<Number> numList2 = new ArrayList<>();

        // Works
        copyElements1(intList,intList2);         // from int to int
        copyElements1(doubleList,doublesList2);  // from double to double


     static <T> void copyElements1(Collection<T> src, Collection<T> dest) {
        for(T n : src){
            dest.add(n);
         }
      }


     // Let's try to copy intList to its supertype
     copyElements1(intList,numList2); // error, method signature just says "T"
                                      // and here the compiler is given 
                                      // two types: Integer and Number, 
                                      // so which one shall it be?

     // PECS to the rescue!
     copyElements2(intList,numList2);  // possible



    // copy Integer (? extends T) to its supertype (Number is super of Integer)
    private static <T> void copyElements2(Collection<? extends T> src, 
                                          Collection<? super T> dest) {
        for(T n : src){
            dest.add(n);
        }
    }

tl；博士：“PECS”是从藏品的角度来看的。如果您只是从泛型集合中提取项，那么它是一个生产者，您应该使用extends；如果你只是在填充物品，那么它是一个消费者，你应该使用super。如果同时使用同一集合，则不应使用extends或super。

假设您有一个方法，它以一个集合作为参数，但您希望它比只接受集合＜Thing＞更灵活。

案例1：你想通过收集并处理每个项目。那么列表是一个生产者，因此您应该使用集合<？扩展Thing>。

理由是集合<？extendsThing>可以保存Thing的任何子类型，因此当您执行操作时，每个元素都将表现为Thing。（实际上不能向集合中添加任何内容（null除外）<？扩展Thing>，因为您无法在运行时知道集合持有Thing的哪个特定子类型。）

案例2：您想要向集合中添加内容。那么列表是消费者，因此您应该使用集合<？超级事物>。

这里的理由是，不同于集合<？扩展Thing>，Collection<？super Thing>可以始终保存Thing，无论实际参数化类型是什么。在这里，只要它允许添加Thing，您就不在乎列表中已经存在什么；这是什么？super Thing保证。

PECS：生产者延伸和消费者超级

理解的前提条件：

泛型和泛型通配符多态性、亚型和超型

假设我们有一个采用泛型类型参数T的类型，例如List＜T＞。当我们编写代码时，还允许泛型类型参数T的子类型或超类型可能是有益的。这放松了对API用户的限制，可以使代码更加灵活。

让我们先看看放松这些限制会带来什么。假设我们有以下3个类：

class BaseAnimal{};

class Animal extends BaseAnimal{};

class Duck extends Animal{};

我们正在构建一个公共方法，该方法采用列表＜Animal＞

如果我们使用超级列表<？superAnimal>而不是List<Animal>，我们现在可以传递更多的列表来满足我们方法的要求。我们现在可以传入List<Animal>或List<BaseAnimal>甚至List<Object>如果我们使用扩展列表<？扩展Animal>而不是List<Animal>，我们现在可以传递更多的列表来满足我们方法的要求。我们现在可以传入List<Animal>或List<Duck>

然而，这存在以下两个限制：

如果我们使用像List<？super Animal>我们不知道List＜t＞的确切类型。它可能是List＜Animal＞或List＜BaseAnimal>或List＜Object＞的列表。我们无从得知。这意味着我们永远无法从列表中获取值，因为我们不知道该类型是什么。但是，我们可以将任何Animal数据类型或将其扩展到列表中。因为我们只能将数据放入列表，所以它被称为数据消费者。如果我们使用扩展列表<？扩展Animal>而不是List＜Animal＞。我们也不知道确切的类型是什么。它可以是List<Animal>或List<Duck>。我们现在不能在列表中添加一些东西，因为我们永远无法确定是什么类型。但是我们可以删除一些东西，原因是我们始终知道列表中的任何东西都是Animal的子类型。因为我们只能从列表中提取数据，所以它被称为数据的生产者。

这里有一个简单的程序来说明类型限制的放松：

import java.util.ArrayList;
import java.util.List;

public class Generics {
    public static void main(String[] args) {

        Generics generics = new Generics();

        generics.producerExtends(new ArrayList<Duck>());
        generics.producerExtends(new ArrayList<Animal>());

        generics.consumerSuper(new ArrayList<Object>());
        generics.consumerSuper(new ArrayList<Animal>());

    }

    //  ? extends T   is an upper bound
    public void producerExtends (List<? extends Animal> list) {

        // Following are illegal since we never know exactly what type the list will be
        // list.add(new Duck());
        // list.add(new Animal());
        
        // We can read from it since we are always getting an Animal or subclass from it
        // However we can read them as an animal type, so this compiles fine
        if (list.size() > 0) {
            Animal animal = list.get(0);
        }
    }

    // ? extends T   is a lower bound
    public void consumerSuper (List<? super Animal> list) {
        // It will be either a list of Animal or a superclass of it
        // Therefore we can add any type which extends animals
        list.add(new Duck());
        list.add(new Animal());

        // Compiler won't allow this it could potentially be a super type of Animal
        // Animal animal = list.get(0);
    }

PECS“规则”仅确保以下内容合法：

消费者：什么？它可以合法地指代T制片人：什么？是的，它可以在法律上被T

列表中的典型配对<？扩展T>生产者，列表<？super T>使用者只是确保编译器可以强制执行标准的“is-A”继承关系规则。如果我们可以合法地这样做，那么说＜T extends？＞、＜？extended T>（或者在Scala中更好，如您所见，它是[-T]，[+T]。不幸的是，我们能做的最好的是<？super T>，<？extended T>。

当我第一次遇到这种情况并在脑海中分解时，机制是有道理的，但代码本身对我来说仍然很困惑——我一直在想“似乎边界不应该像那样颠倒”——尽管我对上面的内容很清楚——这只是为了保证遵守标准参考规则。

帮助我的是将普通作业作为类比。

考虑以下（非生产就绪）玩具代码：

// copies the elements of 'producer' into 'consumer'
static <T> void copy(List<? extends T> producer, List<? super T> consumer) {
   for(T t : producer)
       consumer.add(t);
}

用任务类比来说明这一点，对于消费者来说？通配符（未知类型）是引用-赋值的“左侧”-和<？超级T>确保了什么？T“is-A”？-T可以分配给它，因为？是T的超类型（或最多相同类型）。

对于制片人来说，他们的担忧是一样的，只是颠倒了：制片人的？通配符（未知类型）是指代-赋值的“右手边”-和<？扩展T>确保了什么？是“IS-A”T-它可以分配给T，因为？是T的子类型（或至少相同类型）。

正如我在回答另一个问题时所解释的，PECS是乔什·布洛克（Josh Bloch）为帮助记住Producer extends和Consumer super而创建的助记符设备。

这意味着当传递给方法的参数化类型将生成T的实例（它们将以某种方式从中检索）时？应该使用extends T，因为T的子类的任何实例也是T。当传递给方法的参数化类型将消耗T的实例（它们将传递给它以执行某些操作）时？应该使用super T，因为T的实例可以合法地传递给任何接受某个T超类型的方法。例如，可以在Collection＜Integer＞上使用Comparator＜Number＞？extends T无法工作，因为Comparator＜Integer＞无法对Collection＜Number＞进行操作。

请注意，通常您只应使用？延伸T和？super T表示某些方法的参数。方法应该只使用T作为泛型返回类型的类型参数。

协方差：接受子类型相反：接受超类型

协变类型是只读的，而逆变类型是只写的。