来自 Joshua Bloch 的《Effective Java》:
协变只是意味着如果 X 是 Y 的子类型，则 X[] 也将是 Y[] 的子类型。数组是协变的，因为字符串是 Object 的子类型，所以
String[] 是 Object[] 的子类型
不变只是意味着无论 X 是否是 Y 的子类型，
List<X> will not be subType of List<Y>.
我的问题是为什么在Java中将数组协变？还有其他的SO帖子，比如为什么数组是不变的，但列表是协变的，但它们似乎专注于Scala，我无法理解。
通过维基百科：
这段文字回答了一个问题：“为什么数组是协变的？”或者更准确地说，“为什么在当时数组被设计成协变的？” 当引入泛型时，出于Jon Skeet在这篇回答中指出的原因，它们故意没有被设计成协变。Early versions of Java and C# did not include generics (a.k.a. parametric polymorphism).
In such a setting, making arrays invariant rules out useful polymorphic programs. For example, consider writing a function to shuffle an array, or a function that tests two arrays for equality using the
Object.equalsmethod on the elements. The implementation does not depend on the exact type of element stored in the array, so it should be possible to write a single function that works on all types of arrays. It is easy to implement functions of typeboolean equalArrays (Object[] a1, Object[] a2); void shuffleArray(Object[] a);However, if array types were treated as invariant, it would only be possible to call these functions on an array of exactly the type
Object[]. One could not, for example, shuffle an array of strings.Therefore, both Java and C# treat array types covariantly. For instance, in C#
string[]is a subtype ofobject[], and in JavaString[]is a subtype ofObject[].
No, a
List<Dog>is not aList<Animal>. Consider what you can do with aList<Animal>- you can add any animal to it... including a cat. Now, can you logically add a cat to a litter of puppies? Absolutely not.// Illegal code - because otherwise life would be Bad List<Dog> dogs = new List<Dog>(); List<Animal> animals = dogs; // Awooga awooga animals.add(new Cat()); Dog dog = dogs.get(0); // This should be safe, right?Suddenly you have a very confused cat.
维基百科文章中描述数组协变的原始动机并不适用于泛型，因为通配符使得协变（和逆变）的表达成为可能，例如：
boolean equalLists(List<?> l1, List<?> l2);
void shuffleList(List<?> l);
Object[] num = new Number[4]; num[1]= 5; num[2] = 5.0f; num[3]=43.4; System.out.println(Arrays.toString(num)); num[0]="hello"; - eagertoLearnArrayStoreException 异常，这是正确的。显然，当时认为这是一个值得妥协的地方。与之形成对比的是，现在许多人认为数组协变是一个错误，在事后看来如此。 - Paul Bellora原因是每个数组在运行时都知道其元素类型，而由于类型擦除，通用集合则不知道其元素类型。
例如：
String[] strings = new String[2];
Object[] objects = strings; // valid, String[] is Object[]
objects[0] = 12; // error, would cause java.lang.ArrayStoreException: java.lang.Integer during runtime
List<String> strings = new ArrayList<String>();
List<Object> objects = strings; // let's say it is valid
objects.add(12); // invalid, Integer should not be put into List<String> but there is no information during runtime to catch this
但是，当有人尝试访问该列表时，这会导致问题：
String first = strings.get(0); // would cause ClassCastException, trying to assign 12 to String
也许这篇文章能帮到您：
泛型不支持协变
Java语言中的数组是支持协变的 -- 这意味着如果Integer是Number的子类（事实如此），那么一个Integer也是一个Number，一个Integer[]也是一个Number[]，您可以自由地将一个Integer[]传递或赋值给一个需要Number[]的位置。（更正式地说，如果Number是Integer的超类型，则Number[]是Integer[]的超类型。）您可能认为泛型类型也是如此 -- List<Number>是List<Integer>的超类型，您可以将List<Integer>传递给需要List<Number>的位置。不幸的是，事实并非如此。
原来泛型不支持协变有一个很好的理由：这样会破坏泛型本应提供的类型安全性。想象一下，如果您可以将一个List<Integer>赋值给一个List<Number>，那么以下代码将允许您将一个非Integer类型的东西放入List<Integer>中：
List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));
List<Number>，所以将Float添加到其中似乎完全合法。但是如果ln与li别名，则会破坏li定义中隐含的类型安全承诺——它是整数列表，这就是为什么泛型类型不可能是协变的原因。ArrayStoreException异常。 - Sotirios DelimanolisAnimal派生类的数组，不必接受来自其他地方的任何项目”和“必须只包含Animal的数组，并且必须愿意接受外部提供的Animal引用”。需要前者的代码应该接受Cat数组，但需要后者的代码不应该。如果编译器能够区分这两种类型，它可以提供编译时检查。不幸的是，唯一区分它们的... - supercat参数化类型的一个重要特性是能够编写多态算法，即操作数据结构而不考虑其参数值的算法，例如Arrays.sort()。
使用泛型，可以通过通配符类型来实现：
<E extends Comparable<E>> void sort(E[]);
void sort(Comparable[]);
String[] strings = {"hello"};
Object[] objects = strings;
objects[0] = 1; // throws ArrayStoreException
需要对引用类型数组的每个写入访问进行运行时检查。
简而言之，泛型所代表的新方法使类型系统更加复杂，但也更加静态类型安全，而旧方法则更简单，但静态类型安全性较低。语言设计者选择了更简单的方法，因为他们有更重要的事情要做，而不是关闭类型系统中很少出现问题的小漏洞。后来，在Java确立并解决了紧迫的需求后，他们有资源为泛型做正确的处理（但更改数组会破坏现有的Java程序）。
数组之所以是协变的，至少有两个原因：
对于永远不会更改的信息的集合来说，协变非常有用。要使T的集合协变，其后备存储也必须是协变的。虽然可以设计一个不使用T[]作为后备存储的不可变T集合（例如使用树或链表），但这样的集合可能不如由数组支持的集合性能好。可以认为提供协变不可变集合的更好方法是定义一种“协变不可变数组”类型，它们可以使用作为后备存储，但仅允许数组协变可能更容易。
代码经常会通过不知道将要在其中放置什么类型的内容而对数组进行修改，但不会将任何未从同一数组中读取的内容放入该数组。排序代码是一个典型例子。从概念上讲，数组类型可能包括交换或排列元素的方法（这些方法同样适用于任何数组类型），或定义一个“数组操作器”对象，它保存对数组和已从中读取的一个或多个东西的引用，并且可以包括将先前读取的项目存储到它们来自的数组中的方法。如果数组不是协变的，则用户代码将无法定义此类类型，但运行时可以包含一些专门的方法。
数组是协变的事实可能被视为一个丑陋的hack，但在大多数情况下，它有助于创建可工作的代码。
我认为他们在最初使数组协变方面做出了错误的决定。正如这里所描述的那样，它破坏了类型安全性，因此他们因为向后兼容而被困扰，并且在此之后尝试避免在泛型中犯同样的错误。 这也是Joshua Bloch在书籍《Effective Java(第二版)》的第25条建议中更喜欢使用列表(lists)而不是数组。
JLS还解释了几行，......子类型不会扩展到泛型类型：T <: U并不意味着
C<T><:C<U>...
LinkedList。 - Paul Bellora