L'image ci-dessus est la description dans "Alibaba Java Development Manual v1.2.0". Voici un contre-exemple, disant que la situation d'égalité n'est pas gérée, mais je pense :
o1.getId() > o2.getId()
N'est-ce pas l'inverse
o1.getId() <= o2.getId()
Je l'utilise habituellement comme ça. Pourriez-vous s'il vous plaît m'aider à expliquer la technique de cet endroit ? quelle est la raison?
Après une meilleure compréhension, la cause première du problème est que l'implémentation du tri du JDK7 a été modifiée en TimSort. Voir cet article pour plus de détails.
http://blog.2baxb.me/archives...
Quand j’ai répondu pour la première fois, je n’ai pas bien compris l’intention de l’auteur en posant la question, j’ai donc répondu un peu précipitamment et je m’en excuse.
Le contenu de la réponse précédente est divisé hors ligne. Parce qu'il y a une discussion avec @wanghaa sur l'ancienne réponse dans les commentaires de réponse, elle est conservée. Merci @wanghaa de m'avoir fait prendre conscience du problème.
Le code ci-dessus affichera -1. Si les deux valeurs comparées sont égales, 0 doit être renvoyé. Renvoyer -1 est définitivement faux, la situation d'égalité doit donc être traitée séparément.
Il faut juger qu'il est égal à 0
Après la discussion de @gemoji, je comprends enfin. Pour résumer :
Dans les versions antérieures à JDK7, tout comme ce qui est dit dans Effective Java, Comparator n'est pas obligatoire pour implémenter les égaux
Dans les versions postérieures à JDK7, TimSort est utilisé pour le tri. . L'algorithme, résultant en Comparator doit implémenter égal à.
<<Version chinoise Java efficace>> Il contient une explication détaillée. En fait, il s'agit d'une forte suggestion qui détruit en fait la transitivité
.et la symétrie des égaux et de la comparaison