的数组。Equals (array1, array2):

检查两个数组是否包含相同数量的元素，并且两个数组中所有对应的元素对都相等。

array1.equals(array2):

将该对象与另一个对象进行比较，只有当两个对象的引用相等时才返回true，就像在object .equals()中那样

这是一个臭名昭著的问题:数组的.equals()被严重破坏了，永远不要使用它。

也就是说，它并不是“坏了”，就像“某人以一种非常错误的方式做了这件事”——它只是做了定义的事情，而不是通常期望的事情。所以对于纯粹主义者来说:它完全没问题，这也意味着，永远不要使用它。

现在，等号的预期行为是比较数据。默认的行为是比较身份，因为Object没有任何数据(对于纯粹主义者来说:是的，它有，但这不是重点);假设你在子类中需要等号，你会实现它。在数组中，没有实现，所以你不应该使用它。

区别在于，数组。equals(array1, array2)工作如你所料(即比较内容)，array1.equals(array2)回落到Object。equals实现，它反过来比较身份，因此最好用==代替(对于纯粹主义者:是的，我知道null)。

问题是，即使是数组。如果数组的元素没有正确地实现Equals，那么Equals (array1, array2)会让你很难受。我知道这是一个非常天真的说法，但有一个非常重要的不太明显的情况:考虑一个2D数组。

在Java中，2D数组是数组的数组，而数组的等号是坏的(如果你愿意，也可以是无用的)，所以数组。equals(array1, array2)在2D数组上不能正常工作。

array1.equals(array2)与array1 == array2相同，即它是同一个数组吗?正如@alf所指出的，这不是大多数人所期望的。

数组。Equals (array1, array2)比较数组的内容。

类似地，array. tostring()可能不是很有用，你需要使用Arrays.toString(array)。

叹息。回到70年代，我是IBM 370系统的“系统程序员”(系统管理员)，我的雇主是IBM用户组SHARE的成员。有时会发生这样的情况:有人提交了一份关于某些CMS命令的一些意外行为的APAR(错误报告)，IBM会回复NOTABUG:该命令执行了它被设计要做的事情(以及文档所说的)。

SHARE对此提出了一个反驳:坏——按设计的样子坏掉。我认为这可能适用于数组的等号运算的实现。

Object.equals的实现没有任何问题。对象没有数据成员，因此没有可供比较的内容。两个“Object”是相等的，当且仅当它们实际上是相同的Object(在内部，相同的地址和长度)。

但这种逻辑不适用于数组。数组有数据，您希望通过比较(通过等号)来比较数据。理想情况下，和Arrays. deepequals一样，但至少和Arrays. deepequals一样。Equals(元素的简单比较)。

所以问题是数组(作为内置对象)不会重写object .equals。String(作为命名类)重写Object。等于并给出你期望的结果。

其他给出的答案是正确的:[…].equals([....])只是比较指针而不是内容。也许有一天会有人纠正这一点。或者也许不是:如果[…]，有多少现有的程序会中断。等于实际上比较了元素?我猜不是很多，但肯定多于零。

数组的equals()是从Object继承的，所以它不查看数组的内容，它只认为每个数组等于它自己。

arrays .equals()方法确实比较数组的内容。所有基本类型都有重载，对象的重载使用对象自己的equals()方法。

数组从Object继承equals()，因此compare仅在将数组与自身进行比较时返回true。

另一方面，数组。Equals比较数组中的元素。

这段代码说明了两者的区别:

Object o1 = new Object();
Object o2 = new Object();
Object[] a1 = { o1, o2 };
Object[] a2 = { o1, o2 };
System.out.println(a1.equals(a2)); // prints false
System.out.println(Arrays.equals(a1, a2)); // prints true

请参见Arrays.equals()。另一个静态方法可能也很有趣:Arrays.deepEquals()。