我正在使用将对象添加到 TreeSet。而且我从不在任何基于哈希的集合中使用它。我觉得 TreeSet 需要覆盖 compareTo 方法等于不需要覆盖方法。不覆盖 equals 方法是一种好习惯吗？如果否，那么为什么需要 equals 方法覆盖，因为我不会在基于哈希的集合中使用它？
更新：javadoc 说，
强烈建议但不严格要求 (x.compareTo(y)==0) == (x.equals(y))。一般来说，任何实现了 Comparable 接口并违反此条件的类都应该清楚地表明这一事实。推荐的语言是“注意：这个类有一个与equals不一致的自然顺序。”
老实说，我不明白平等实施的强烈建议背后的原因。
最佳做法是始终保持hashCode()一致equals()。
你不知道下周你可能会在 HashMap 中使用它，而其他使用你的类的人也会认为它已经完成。
为什么需要equals方法覆盖，因为我不会在基于哈希的集合中使用它？
该equals方法需要避免意外。你说你不会在基于哈希的集合中使用它；但其他人可能。我什至会说你自己可能会TreeSet在HashSet不记得你需要添加等于的情况下改变。
这只是一个原因，一个实例为什么你应该实现equals与compareTo. 你可以想到其他人，但本质上它们都指的是一致性——如果那样的x.compareTo(y) == 0话，这很直观x.equals(y)。
覆盖equals()与散列容器无关。这与你是否想要一个自定义的类平等概念有关。如果你覆盖compareTo()，那么你这样做，所以为了简单的正确性，你应该覆盖equals()。
覆盖hashCode()也与散列容器关系不大。它恰好被他们使用，但其他东西也可以使用哈希码。您应该始终与;保持hashCode()同步。equals()没有理由不这样做。
强烈建议是为了尽量减少意外。如果compareTo()返回 0，那么我希望这两个对象相等 - 如果不同意，那将非常混乱equals()。
equals使用而不是运算符来比较您的 java 对象总是好的或相当必要的==。因为在 equals 实现中，您可以将对象与其属性值进行比较。而使用 ==，您只能检查两个引用是否指向同一个内存对象。
在散列集合的情况下，由于对象检索的复杂性，它变得更加重要。