哈希冲突到底是什么？它是一项功能或常见现象，但误操作但可以避免吗？
这是一个功能。它是由hashCode的本质引起的：从较大的值空间到较小的值空间的映射。根据设计和意图，将会发生冲突。
到底是什么导致哈希冲突-自定义类的hashCode（）方法的错误定义，
不良的设计会使情况变得更糟，但这在概念上是地方性的。
或保留不覆盖equals（）方法，同时不完美地覆盖hashCode（）方法的情况，
没有。
还是不是由开发人员来决定的，许多流行的Java库中都有可能导致哈希冲突的类？
这真的没有道理。哈希表早晚会冲突的，糟糕的算法会使其早日崩溃。就是这样
哈希冲突发生时，有什么地方出错或意外吗？
如果哈希表被正确写入，则不是。哈希冲突仅表示hashCode不是唯一的，这使您进入调用
equals()，并且重复次数越多，性能就越差。
我的意思是说有什么原因可以避免哈希冲突？
您必须权衡易于计算和价值分散的问题。没有单一的黑白答案。
Java是否在对象初始化期间为每个类生成或至少尝试生成唯一的hasCode？
不能。“唯一哈希码”在术语上是矛盾的。
如果不是，仅依靠Java来确保我的程序不会在JRE类的Hash
Collision中运行是否正确？如果不合适，那么如何避免将最终类（例如String）作为键的hashmap的哈希冲突？
这个问题毫无意义。如果您使用的
String是散列算法，那么您别无选择，您还使用的是其hashCode已被专家奴役二十多年的类。
