答案和其他答案都是正确的。我将用我认为会有帮助的解决方案来补充这些答案。我认为这在编程中经常出现。需要注意的一点是，对于集合（列表、集合等），主要问题是添加到集合。这就是问题所在。即使移除也可以。

在大多数情况下，我们可以使用集合<？扩展T>而不是集合<T>，这应该是首选。然而，我发现这样做并不容易。关于这是否始终是最好的做法，这是一个值得争论的问题。我在这里介绍一个类DownCastCollection，它可以转换集合<？将T>扩展到集合<T>（我们可以为List、Set、NavigableSet等定义类似的类），以便在使用标准方法时使用。下面是一个如何使用它的示例（在这种情况下，我们也可以使用Collection<？extendsObject>，但我保持简单，以说明使用DownCastCollection。

/**Could use Collection<? extends Object> and that is the better choice. 
* But I am doing this to illustrate how to use DownCastCollection. **/

public static void print(Collection<Object> col){  
    for(Object obj : col){
    System.out.println(obj);
    }
}
public static void main(String[] args){
  ArrayList<String> list = new ArrayList<>();
  list.addAll(Arrays.asList("a","b","c"));
  print(new DownCastCollection<Object>(list));
}

现在开始上课：

import java.util.AbstractCollection;
import java.util.Collection;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class DownCastCollection<E> extends AbstractCollection<E> implements Collection<E> {
private Collection<? extends E> delegate;

public DownCastCollection(Collection<? extends E> delegate) {
    super();
    this.delegate = delegate;
}

@Override
public int size() {
    return delegate ==null ? 0 : delegate.size();
}

@Override
public boolean isEmpty() {
    return delegate==null || delegate.isEmpty();
}

@Override
public boolean contains(Object o) {
    if(isEmpty()) return false;
    return delegate.contains(o);
}
private class MyIterator implements Iterator<E>{
    Iterator<? extends E> delegateIterator;

    protected MyIterator() {
        super();
        this.delegateIterator = delegate == null ? null :delegate.iterator();
    }

    @Override
    public boolean hasNext() {
        return delegateIterator != null && delegateIterator.hasNext();
    }

    @Override
    public  E next() {
        if(!hasNext()) throw new NoSuchElementException("The iterator is empty");
        return delegateIterator.next();
    }

    @Override
    public void remove() {
        delegateIterator.remove();

    }

}
@Override
public Iterator<E> iterator() {
    return new MyIterator();
}



@Override
public boolean add(E e) {
    throw new UnsupportedOperationException();
}

@Override
public boolean remove(Object o) {
    if(delegate == null) return false;
    return delegate.remove(o);
}

@Override
public boolean containsAll(Collection<?> c) {
    if(delegate==null) return false;
    return delegate.containsAll(c);
}

@Override
public boolean addAll(Collection<? extends E> c) {
    throw new UnsupportedOperationException();
}

@Override
public boolean removeAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.removeAll(c);
}

@Override
public boolean retainAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.retainAll(c);
}

@Override
public void clear() {
    if(delegate == null) return;
        delegate.clear();

}

}

子类型对于参数化类型是不变的。即使严格来说，类Dog是Animal的子类型，但参数化类型List＜Dog＞不是List＜Animal＞的子类型。相反，协变子类型由数组使用，因此数组类型狗[]是动物[]的一个亚型。

不变的子类型确保不违反Java强制的类型约束。考虑@Jon Skeet给出的以下代码：

List<Dog> dogs = new ArrayList<Dog>(1);
List<Animal> animals = dogs;
animals.add(new Cat()); // compile-time error
Dog dog = dogs.get(0);

正如@Jon Skeet所说，这段代码是非法的，因为否则它会违反类型约束，在狗期望的时候返回一只猫。

将上述代码与数组的类似代码进行比较是有指导意义的。

Dog[] dogs = new Dog[1];
Object[] animals = dogs;
animals[0] = new Cat(); // run-time error
Dog dog = dogs[0];

该代码是合法的。但是，引发数组存储异常。数组在运行时携带其类型，JVM可以这样强制协变子类型的类型安全性。

为了进一步理解这一点，让我们看一下javap生成的字节码：

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

public class Demonstration {
    public void normal() {
        List normal = new ArrayList(1);
        normal.add("lorem ipsum");
    }

    public void parameterized() {
        List<String> parameterized = new ArrayList<>(1);
        parameterized.add("lorem ipsum");
    }
}

使用命令javap-c演示，这将显示以下Java字节码：

Compiled from "Demonstration.java"
public class Demonstration {
  public Demonstration();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void normal();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return

  public void parameterized();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return
}

观察方法体的翻译代码是否相同。编译器通过删除来替换每个参数化类型。此属性至关重要，这意味着它不会破坏向后兼容性。

总之，参数化类型的运行时安全性是不可能的，因为编译器通过删除来替换每个参数化类型。这使得参数化类型只不过是语法糖。

我认为，其他答案中提到的一点是

List＜Dog＞不是Java中的List＜Animal＞

这也是事实

狗的列表是英文的动物列表（在合理的解释下）

OP的直觉运作方式——当然这是完全有效的——是后一句话。然而，如果我们运用这种直觉，我们得到的语言在其类型系统中不是Java风格的：假设我们的语言确实允许将猫添加到我们的狗列表中。这意味着什么？这意味着该列表不再是狗的列表，而仅仅是动物的列表。还有一张哺乳动物的列表和一张四足动物的列表。

换一种说法：Java中的List＜Dog＞在英语中并不意味着“一个狗的列表”，它的意思是“一个只有狗的列表。”。

更一般地说，OP的直觉倾向于一种语言，在这种语言中，对对象的操作可以改变其类型，或者更确切地说，对象的类型是其值的（动态）函数。

关于Jon Skeet的回答，他使用了以下示例代码：

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new ArrayList<Dog>(); // ArrayList implements List
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

在最深层次上，这里的问题是狗和动物共享一个参考。这意味着一种方法是复制整个列表，这将打破引用相等：

// This code is fine
List<Dog> dogs = new ArrayList<Dog>();
dogs.add(new Dog());
List<Animal> animals = new ArrayList<>(dogs); // Copy list
animals.add(new Cat());
Dog dog = dogs.get(0);   // This is fine now, because it does not return the Cat

在调用List＜Animal＞animals＝new ArrayList＜＞（狗）；后；，您随后不能将动物直接分配给狗或猫：

// These are both illegal
dogs = animals;
cats = animals;

因此，您不能将错误的Animal子类型放入列表中，因为没有错误的子类型--任何子类型的对象？扩展动物可以添加到动物。

显然，这改变了语义，因为动物和狗的列表不再共享，所以添加到一个列表不会添加到另一个列表中（这正是您想要的，以避免将猫添加到只应包含狗对象的列表中的问题）。此外，复制整个列表可能效率低下。然而，通过打破引用相等性，这确实解决了类型等价问题。

问题已正确识别为与差异有关，但详细信息不正确。纯函数列表是协变数据函子，这意味着如果Sub类型是Super的子类型，那么Sub列表绝对是Super列表的子类型。

然而，列表的可变性并不是这里的基本问题。问题是总体上的可变性。这个问题是众所周知的，被称为协方差问题，我认为它是卡斯塔尼亚首先发现的，它完全彻底地破坏了作为一个通用范式的对象定向。这是基于Cardelli和Reynolds之前建立的方差规则。

有点过于简单化，让我们将T型对象B分配给T型对象A作为突变。这不失一般性：a的突变可以写成a=f（a），其中f:T->T。当然，问题是，虽然函数在其共域中是协变的，但它们在其域中是逆变的，但通过赋值，域和共域是相同的，因此赋值是不变的！

因此，概括而言，亚型不能突变。但是对象定向突变是根本的，因此对象定向本质上是有缺陷的。

这里有一个简单的例子：在纯函数设置中，对称矩阵显然是一个矩阵，它是一个子类型，没有问题。现在，让我们在矩阵中添加一项功能，即在坐标（x，y）处设置一个元素，规则是其他元素不变。现在对称矩阵不再是一个子类型，如果你改变了（x，y），你也改变了（y，x）。函数运算是delta:Sym->Mat，如果你改变对称矩阵的一个元素，你会得到一个一般的非对称矩阵。因此，如果在Mat中包含“更改一个元素”方法，Sym不是子类型。事实上几乎肯定没有合适的亚型。

简单地说，如果你有一个通用的数据类型，其中包含大量的变异器，这些变异器利用了它的通用性，你可以确定任何适当的子类型都不可能支持所有这些变异：如果可以，它将与超类型一样通用，与“适当”子类型的规范相反。

事实上，Java阻止了可变列表的子类型化，这并不能解决真正的问题：几十年前，当Java受到质疑时，为什么要使用面向对象的垃圾呢？？

无论如何，这里有一个合理的讨论：

https://en.wikipedia.org/wiki/Covariance_and_contravariance_（计算机科学）

让我们以JavaSE教程为例

public abstract class Shape {
    public abstract void draw(Canvas c);
}

public class Circle extends Shape {
    private int x, y, radius;
    public void draw(Canvas c) {
        ...
    }
}

public class Rectangle extends Shape {
    private int x, y, width, height;
    public void draw(Canvas c) {
        ...
    }
}

因此，为什么狗（圆圈）的列表不应被视为动物（形状）的列表，是因为这种情况：

// drawAll method call
drawAll(circleList);


public void drawAll(List<Shape> shapes) {
   shapes.add(new Rectangle());    
}

因此，Java“架构师”有两个选项可以解决这个问题：

不要认为子类型是隐式的，它是父类型，并给出编译错误，就像现在发生的那样将子类型视为它的父类型，并在编译“add”方法时进行限制（因此在drawAll方法中，如果要传递圆的列表（形状的子类型），编译器应该检测到这一点，并用编译错误限制您这样做）。

出于明显的原因，他们选择了第一条路。