我将尝试总结评论中提出的三个更合理的版本。
@霍尔格说：
我猜想这是为了避免java.util.Arrays类被加载为此方法的副作用。对于应用程序代码，通常不必担心。
这是最容易测试的东西。让我们编译这样的程序：
public class HashMapTest {
public static void main(String[] args) {
new java.util.HashMap();
}
}
使用运行它java -verbose:class HashMapTest。这将在发生类加载事件时将其打印出来。使用JDK 1.8.0_60，我看到加载了400多个类：
... 155 lines skipped ...
[Loaded java.util.Set from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.AbstractSet from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptySet from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptyList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptyMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableCollection from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableRandomAccessList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.Reflection from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
**[Loaded java.util.HashMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.HashMap$Node from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$3 from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$ReflectionData from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$Atomic from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.AbstractRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.GenericDeclRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.ClassRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$AnnotationData from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.annotation.AnnotationType from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.WeakHashMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.ClassValue$ClassValueMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.reflect.Modifier from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.LangReflectAccess from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.reflect.ReflectAccess from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
**[Loaded java.util.Arrays from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
...
如您所见，HashMap会在应用程序代码之前加载很久，而Arrays在之后仅加载14个类HashMap。该HashMap负载由触发sun.reflect.Reflection初始化，因为它有HashMap静态字段。该Arrays负载可能被触发WeakHashMap，实际上有负载Arrays.fill的clear()方法。该WeakHashMap负载由触发java.lang.ClassValue$ClassValueMap延伸WeakHashMap。该ClassValueMap存在于每个java.lang.Class实例。在我看来，没有Arrays类，JDK根本无法初始化。另外，Arrays初始化很短一成不变的，它只是初始化断言机制。此机制还用于许多其他类（例如，java.lang.Throwable这是很早加载的）。不会执行其他静态初始化步骤java.util.Arrays。因此，@ Holger版本对我来说似乎不正确。
在这里，我们还发现了非常有趣的东西。在WeakHashMap.clear()仍然使用Arrays.fill。它出现在这里很有趣，但是不幸的是，这发生在史前时代（它已经存在于第一个公共OpenJDK存储库中）。
接下来，@ MarcoTopolnik说：
当然不是更安全，但是当呼叫未内联且很短时，它可能会更快。在HotSpot上，循环和显式调用都将导致快速的编译器内部函数（在欢乐时光中）。filltabfill
令我惊讶的是，Arrays.fill它没有被直接内化（请参阅@apangin生成的内在列表）。似乎这种循环可以被JVM识别和向量化，而无需显式的内部处理。因此，在非常特殊的情况下（例如，如果达到限制），不能内联额外的呼叫，这是事实。另一方面，这是非常罕见的情况，它仅是单个调用，不是循环内调用，而是静态（而不是虚拟/接口）调用，因此，性能提升可能仅是微不足道的，并且仅在某些特定情况下才有效。JVM开发人员通常不在乎的事情。MaxInlineLevel
还应注意，即使C1“客户端”编译器（1-3层）也能够内联Arrays.fill调用，例如in WeakHashMap.clear()，如内联log（-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining）所示：
36 3 java.util.WeakHashMap::clear (50 bytes)
!m @ 4 java.lang.ref.ReferenceQueue::poll (28 bytes)
@ 17 java.lang.ref.ReferenceQueue::reallyPoll (66 bytes) callee is too large
@ 28 java.util.Arrays::fill (21 bytes)
!m @ 40 java.lang.ref.ReferenceQueue::poll (28 bytes)
@ 17 java.lang.ref.ReferenceQueue::reallyPoll (66 bytes) callee is too large
@ 1 java.util.AbstractMap::<init> (5 bytes) inline (hot)
@ 1 java.lang.Object::<init> (1 bytes) inline (hot)
@ 9 java.lang.ref.ReferenceQueue::<init> (27 bytes) inline (hot)
@ 1 java.lang.Object::<init> (1 bytes) inline (hot)
@ 10 java.lang.ref.ReferenceQueue$Lock::<init> (5 bytes) unloaded signature classes
@ 62 java.lang.Float::isNaN (12 bytes) inline (hot)
@ 112 java.util.WeakHashMap::newTable (8 bytes) inline (hot)
当然，它还可以通过功能强大的智能C2“服务器”编译器轻松内联。因此，我在这里看不到任何问题。似乎@Marco版本也不正确。
最后，我们有@StuartMarks（他是JDK开发人员，因此是官方声音）的一些评论：
有趣。我的直觉是这是一个错误。此变更集的审阅线程在这里，它引用的是先前的线程，并在此处继续。该较早线程中的初始消息指向Doug Lea的CVS存储库中的HashMap.java原型。我不知道这是哪里来的。它似乎与OpenJDK历史记录中的任何内容都不匹配。
...无论如何，它可能是一些旧快照；for循环在clear（）方法中使用了很多年。这个changeset引入了Arrays.fill（）调用，因此它只在树中呆了几个月。还要注意，此变更集引入的基于Integer.highestOneBit（）的二次幂计算也同时消失了，尽管已注意到但在本次审查中被忽略了。嗯
事实上，HashMap.clear()包含循环多年被替换与Arrays.fill在2013年4月10日，住少一个半个，直到今年9月4日，当讨论提交了介绍。讨论的提交实际上是对HashMap内部结构的重大重写，以解决JDK-8023463问题。长期以来，人们一直担心HashMap散列码重复的键会毒害密钥，从而将HashMap搜索速度降低为线性，使其容易受到DoS攻击。解决该问题的尝试是在JDK-7中进行的，包括对String hashCode的一些随机化。如此看来HashMap 实现是从较早的提交派生的，是独立开发的，然后合并到master分支中，以覆盖介于两者之间的一些更改。
我们可能会支持这种假设进行比较。就拿版本，其中Arrays.fill移除（2013年9月4日），并将其与比较以前的版本（2013年7月30日）。该diff -U0输出具有4341线。现在，让我们与添加时（2013-04-01）之前的版本进行比较Arrays.fill。现在diff -U0仅包含2680行。因此，新版本实际上比旧版本更像直接父版本。
结论
因此，总而言之，我同意Stuart Marks的观点。没有删除的具体原因Arrays.fill，只是因为中间的更改被错误覆盖。Arrays.fill在JDK代码和用户应用程序中使用都非常好，例如，在中使用过WeakHashMap。Arrays无论如何，该类都是在JDK初始化期间很早就加载的，它具有非常简单的静态初始化器，并且Arrays.fill即使由客户端编译器也可以轻松地内联方法，因此，不应该注意到性能上的缺点。
filltabfill