List<Dog> 是 List<Animal> 的子类吗？为什么 Java 泛型不是隐式多态的？

不，List<Dog> 不是 List<Animal>。考虑一下您可以使用 List<Animal> 做什么 - 您可以将任何动物添加到其中...包括一只猫。现在，你能合乎逻辑地将一只猫添加到一窝小狗中吗？绝对不。

// 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?

突然你有一只非常困惑的猫。

现在，您不能将 Cat 添加到 List<? extends Animal>，因为您不知道它是 List<Cat>。您可以检索一个值并知道它将是一个 Animal，但您不能添加任意动物。 List<? super Animal> 则相反——在这种情况下，您可以安全地向其中添加 Animal，但您对可能从中检索到的内容一无所知，因为它可能是 List<Object>。

---

您要查找的内容称为 covariant type 参数。这意味着如果一种类型的对象可以在方法中替换为另一种类型（例如，Animal 可以替换为 Dog），同样适用于使用这些对象的表达式（因此 List<Animal> 可以替换为 { 5}）。问题是协方差对于一般的可变列表是不安全的。假设您有一个 List<Dog>，并且它被用作 List<Animal>。当您尝试将 Cat 添加到这个实际上是 List<Dog> 的 List<Animal> 时会发生什么？自动允许类型参数是协变的会破坏类型系统。

添加语法以允许将类型参数指定为协变会很有用，这避免了方法声明中的 ? extends Foo，但这确实增加了额外的复杂性。

---

List<Dog> 不是 List<Animal> 的原因是，例如，您可以将 Cat 插入 List<Animal>，但不能插入 List<Dog>...您可以使用通配符使泛型更多在可能的情况下可扩展；例如，从 List<Dog> 读取类似于从 List<Animal> 读取 - 但不是写入。

Generics in the Java Language 和 Section on Generics from the Java Tutorials 对为什么某些事物是或不是多态的或允许使用泛型有一个非常好的、深入的解释。

---

我认为应该在 other answers 提及的内容中添加一点是，虽然

List 不是 Java 中的 List

这也是真的

list of dogs is-a list of animal in English（合理解释下）

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

换句话说：Java 中的 List<Dog> 在英语中并不意味着“狗的列表”，它的意思是“狗的列表，除了狗什么都没有”。

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

---

我会说泛型的全部意义在于它不允许这样做。考虑数组的情况，它确实允许这种类型的协方差：

  Object[] objects = new String[10];
  objects[0] = Boolean.FALSE;

该代码可以正常编译，但会引发运行时错误（第二行中的 java.lang.ArrayStoreException: java.lang.Boolean）。它不是类型安全的。泛型的重点是添加编译时类型安全性，否则您可以坚持使用没有泛型的普通类。

现在有时您需要更加灵活，这就是 ? super Class 和 ? extends Class 的用途。前者是当您需要插入类型 Collection（例如）时，后者是当您需要以类型安全的方式从中读取时。但同时做到这两点的唯一方法是拥有一个特定的类型。

---

要理解这个问题，与数组进行比较很有用。

List<Dog> 不是 List<Animal> 的子类。
但是 Dog[] 是 Animal[] 的子类。

数组是 reifiable 且协变的。
Reifiable 表示它们的类型信息在运行时完全可用。
因此，数组提供运行时类型安全，但不提供编译时类型安全。

    // All compiles but throws ArrayStoreException at runtime at last line
    Dog[] dogs = new Dog[10];
    Animal[] animals = dogs; // compiles
    animals[0] = new Cat(); // throws ArrayStoreException at runtime

对于泛型，反之亦然：
泛型是erased且不变的。
因此，泛型不能提供运行时类型安全，但它们提供编译时类型安全。
在下面的代码中，如果泛型是协变的，则可以在第 3 行创建 heap pollution。

    List<Dog> dogs = new ArrayList<>();
    List<Animal> animals = dogs; // compile-time error, otherwise heap pollution
    animals.add(new Cat());

---

这里给出的答案并没有完全说服我。所以相反，我再举一个例子。

public void passOn(Consumer<Animal> consumer, Supplier<Animal> supplier) {
    consumer.accept(supplier.get());
}

听起来不错，不是吗？但是您只能将 Consumer 和 Supplier 传递给 Animal。如果您有一个 Mammal 消费者，但有一个 Duck 供应商，那么它们应该不适合，尽管两者都是动物。为了禁止这种情况，增加了额外的限制。

代替上面的，我们必须定义我们使用的类型之间的关系。

例如，

public <A extends Animal> void passOn(Consumer<A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

确保我们只能使用为消费者提供正确类型的对象的供应商。

OTOH，我们也可以

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<A> supplier) {
    consumer.accept(supplier.get());
}

我们采用另一种方式：我们定义 Supplier 的类型并限制它可以放入 Consumer。

我们甚至可以做到

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

其中，具有直观关系 Life -> Animal -> Mammal -> Dog、Cat 等，我们甚至可以将 Mammal 放入 Life 消费者，但不能将 String 放入 Life 消费者。

---

这种行为的基本逻辑是 Generics 遵循类型擦除机制。因此，在运行时，您无法识别 collection 的类型，这与没有此类擦除过程的 arrays 不同。所以回到你的问题...

所以假设有一个方法如下：

add(List<Animal>){
    //You can add List<Dog or List<Cat> and this will compile as per rules of polymorphism
}

现在，如果 java 允许调用者将动物类型的列表添加到此方法中，那么您可能会将错误的东西添加到集合中，并且在运行时它也会由于类型擦除而运行。而在数组的情况下，您将在这种情况下获得运行时异常......

因此，从本质上讲，这种行为是被实现的，因此人们不能将错误的东西添加到集合中。现在我相信类型擦除的存在是为了与没有泛型的遗留 java 兼容....

---

实际上你可以使用一个接口来实现你想要的。

public interface Animal {
    String getName();
    String getVoice();
}
public class Dog implements Animal{
    @Override 
    String getName(){return "Dog";}
    @Override
    String getVoice(){return "woof!";}

}

然后您可以使用集合使用

List <Animal> animalGroup = new ArrayList<Animal>();
animalGroup.add(new Dog());

---

对于参数化类型，子类型是 invariant。即使类 Dog 是 Animal 的子类型，参数化类型 List<Dog> 也不是 List<Animal> 的子类型。相反，数组使用 covariant 子类型，因此数组类型 Dog[] 是 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];

该代码是合法的。但是，抛出 array store exception。数组在运行时携带它的类型，这样 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 Demonstration，这将显示以下 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
}

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

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

---

如果您确定列表项是给定超类型的子类，则可以使用以下方法强制转换列表：

(List<Animal>) (List<?>) dogs

当您想在构造函数中传递列表或对其进行迭代时，这很有用。

---

answer 以及其他答案是正确的。我将通过我认为会有所帮助的解决方案来添加这些答案。我认为这在编程中经常出现。需要注意的一点是，对于集合（列表、集合等），主要问题是添加到集合中。那就是事情崩溃的地方。即使删除也可以。

在大多数情况下，我们可以使用 Collection<? extends T> 而不是 Collection<T>，这应该是首选。但是，我发现这样做并不容易。关于这是否总是最好的做法还有待商榷。我在这里展示了一个可以将 Collection<? extends T> 转换为 Collection<T> 的类 DownCastCollection（我们可以为 List、Set、NavigableSet 定义类似的类），以便在使用标准方法非常不方便时使用。下面是一个如何使用它的示例（在这种情况下我们也可以使用 Collection<? extends Object>，但我会保持简单以说明使用 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();

}

}

---

其他人在解释为什么不能只将后代列表转换为超类列表方面做得不错。

但是，许多人访问此问题以寻找解决方案。

所以，现代java中这个问题的解决方案如下：

（注：S = 超类）

List<S> supers = List.copyOf( descendants );

有关为什么这是安全的解释（考虑到其他答案提到的潜在陷阱）以及为什么这是实现此目标的最佳方式，请参阅相关问题和我的 2022 年回答：https://stackoverflow.com/a/72195980/773113

---

该问题已被正确识别为与差异有关，但细节不正确。纯函数列表是协变数据函子，这意味着如果类型 Sub 是 Super 的子类型，则 Sub 列表肯定是 Super 列表的子类型。

然而，列表的可变性不是这里的基本问题。问题通常是可变性。这个问题是众所周知的，被称为协方差问题，我认为它首先是由 Castagna 确定的，它完全彻底地破坏了面向对象作为一种通用范式。它基于 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_(computer_science)

---

让我们以 JavaSE tutorial 中的示例为例

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方法中，如果一个圆圈列表，形状的子类型，将被传递，编译器应该检测到并限制你这样做）。

出于显而易见的原因，那选择了第一种方式。

---

我们还应该考虑编译器如何威胁泛型类：在我们填充泛型参数时“实例化”不同的类型。

因此，我们有 ListOfAnimal、ListOfDog、ListOfCat 等，它们是不同的类，当我们指定泛型参数时，它们最终由编译器“创建”。这是一个扁平的层次结构（实际上关于 List 根本不是层次结构）。

在泛型类的情况下协方差没有意义的另一个论点是，在基础上所有类都是相同的 - 是 List 实例。通过填充泛型参数专门化 List 不会扩展类，它只是使其适用于特定的泛型参数。

---

问题已得到很好的识别。但是有一个解决方案；使 doSomething 通用：

<T extends Animal> void doSomething<List<T> animals) {
}

现在您可以使用 List 或 List 或 List 调用 doSomething。

---

另一个解决方案是建立一个新列表

List<Dog> dogs = new ArrayList<Dog>(); 
List<Animal> animals = new ArrayList<Animal>(dogs);
animals.add(new Cat());

---

除了使用此示例代码的 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?

在最深层次上，这里的问题是 dogs 和 animals 共享一个引用。这意味着完成这项工作的一种方法是复制整个列表，这会破坏引用相等性：

// 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<>(dogs); 后，您不能随后直接将 animals 分配给 dogs 或 cats：

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

因此，您不能将 Animal 的错误子类型放入列表中，因为没有错误的子类型 - 子类型 ? extends Animal 的任何对象都可以添加到 animals。

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

---

我看到这个问题已经被回答了很多次，只是想在同一个问题上输入我的意见。

让我们继续创建一个简化的 Animal 类层次结构。

abstract class Animal {
    void eat() {
        System.out.println("animal eating");
    }
}

class Dog extends Animal {
    void bark() { }
}

class Cat extends Animal {
    void meow() { }
}

现在让我们看看我们的老朋友 Arrays，我们知道它隐式支持多态性——

class TestAnimals {
    public static void main(String[] args) {
        Animal[] animals = {new Dog(), new Cat(), new Dog()};
        Dog[] dogs = {new Dog(), new Dog(), new Dog()};
        takeAnimals(animals);
        takeAnimals(dogs);
    }

    public void takeAnimals(Animal[] animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

该类编译得很好，当我们运行上面的类时，我们得到了输出

animal eating
animal eating
animal eating
animal eating
animal eating
animal eating

这里要注意的一点是，takeAnimals() 方法被定义为接受任何动物类型的东西，它可以接受一个 Animal 类型的数组，也可以接受一个 Dog 数组，因为 Dog-is-a-Animal。所以这就是多态性的作用。

现在让我们对泛型使用同样的方法，

现在假设我们稍微调整一下代码并使用 ArrayLists 而不是 Arrays -

class TestAnimals {
    public static void main(String[] args) {
        ArrayList<Animal> animals = new ArrayList<Animal>();
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        takeAnimals(animals);
    }

    public void takeAnimals(ArrayList<Animal> animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

上面的类将编译并产生输出 -

animal eating
animal eating
animal eating
animal eating
animal eating
animal eating

所以我们知道这是可行的，现在让我们稍微调整一下这个类以多态地使用 Animal 类型 -

class TestAnimals {
    public static void main(String[] args) {
        ArrayList<Animal> animals = new ArrayList<Animal>();
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());

        ArrayList<Dog> dogs = new ArrayList<Dog>();
        takeAnimals(animals);
        takeAnimals(dogs);
    }

    public void takeAnimals(ArrayList<Animal> animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

看起来在编译上述类时应该没有问题，因为 takeAnimals() 方法被设计为采用 Animal 和 Dog-is-a-Animal 类型的任何 ArrayList ，因此在这里它不应该是一个交易破坏者。

但是，不幸的是编译器会抛出一个错误并且不允许我们将 Dog ArrayList 传递给期望 Animal ArrayList 的变量。

你问为什么？

因为想象一下，如果 JAVA 允许将 Dog ArrayList - 狗 - 放入 Animal ArrayList - 动物 - 然后在 takeAnimals() 方法中，有人会做类似的事情 -

animals.add(new Cat());

认为这应该是可行的，因为理想情况下它是一个 Animal ArrayList，并且您应该可以将任何猫添加到它作为 Cat-is-also-a-Animal，但实际上您将 Dog 类型的 ArrayList 传递给它。

所以，现在你一定在想同样的事情也应该发生在数组上。你这样想是对的。

如果有人试图对 Arrays 做同样的事情，那么 Arrays 也会抛出一个错误，但是 Arrays 在运行时处理这个错误，而 ArrayLists 在编译时处理这个错误。

---