Il y a eu un problème lors du traitement de la vérification du montant du paiement au cours des deux derniers jours. J'ai utilisé la méthode égale de BigDecimal pour comparer si les deux montants sont égaux, ce qui a entraîné une erreur de comparaison des montants (comme la comparaison entre 3,0 et 3,00, etc.).
[Remarque: Ce qui suit concerne le Sun JDK version 1.4.2 comme exemple. L'implémentation d'autres versions peut ne pas être cohérente, veuillez l'ignorer]
Tout d'abord, jetons un coup d'œil à la méthode égale de Bigdecimal:
Public Boolean est égal (objet x) {if (! (x instanceof bigdecimal)) return false; bigdecimal xdec = (bigdecimal) x; return scale == xdec.scale && intval.equals (xdec.Intval); }Vous pouvez voir que la méthode Euquals de BigDecimal est de déterminer d'abord le type de données à comparer. Si les types d'objets sont cohérents, il est déterminé en même temps si la précision (échelle) et la valeur (la méthode égale de BigInteger) sont cohérentes.
En fait, il est déjà très clair dans Javadoc: "Compare ce BigDecimal avec l'objet spécifié pour l'égalité. Contrairement à Compareto, cette méthode considère deux objets BigDecimal égaux uniquement s'ils sont égaux en valeur et en échelle (donc 2.0 n'est pas égal à 2,00 par rapport à cette méthode)." Je n'ai tout simplement pas fait attention!
Jetons un coup d'œil à la méthode de comparaison:
public int compareto (Bigdecimal Val) {/ * Optimisation: fonctionnerait bien sans les trois lignes suivantes * / int sigdiff = Signum () - Val.Signum (); if (sigdiff! = 0) RETOUR (Sigdiff> 0? 1: -1); / * si les signes correspondent, l'échelle et la comparaison des intvales * / bigdecimal arg [] = nouveau BigDecal this; arg [1] = val; matchscale (arg); return arg [0] .intval.compareto (arg [1] .intval); } Vous pouvez voir qu'il y a un traitement de MatchScale dans cette méthode, ce qui signifie convertir l'objet avec une faible précision en haute précision, puis en la comparant (également la méthode Compareto de BigInteger). L'implémentation de MatchScale est la suivante:
Matchscale de vide statique privé (bigdecimal [] val) {if (val [0] .scale <val [1] .scale) val [0] = val [0] .setsCale (val [1] .scale); else if (val [1] .scale <val [0] .scale) val [1] = val [1] .setsCale (val [0] .scale); } Faites un test simple:
System.out.println (new BigDecimal ("1.2"). Equals (new BigDecimal ("1.20"))); // sortie falSesystem.out.println (new BigDecimal ("1.2"). Compareto (new BigDecimal ("1.20")) == 0); // Sortie True A également remarqué que le constructeur BigDecimal ci-dessus est passé en cordes. Si le type de nombre passé, que se passera-t-il? Vous pouvez le tester vous-même et analyser les raisons:
System.out.println (new BigDecimal ("1.2"). Equals (new BigDecimal ("1.20"))); // sortie falSesystem.out.println (new BigDecimal ("1.2"). Compareto (new BigDecimal ("1.20")) == 0); // Sortie True System.out.println (new BigDecimal (1.2) .Equals (new BigDecimal ("1.20"))); // la sortie est-ce? System.out.println (new BigDecimal (1.2) .Compareto (new BigDecimal ("1.20")) == 0); // est la sortie? System.out.println (nouveau BigDecimal (1.2) .Equals (nouveau BigDecimal (1.20))); // est la sortie? System.out.println (new BigDecimal (1.2) .Compareto (new BigDecimal (1.20)) == 0); // est la sortie?La conclusion finale est: pour la comparaison des tailles de BigDecimal, l'utilisation de la méthode Equal comparera non seulement la taille de la valeur, mais comparera également la précision des deux objets. La méthode compareto ne comparera pas la précision, mais ne comparera que la taille de la valeur.
Enfin, je me méprise. J'utilise la langue java depuis tant d'années et je n'ai même pas compris le bon sens de base!
L'article ci-dessus parle brièvement de la différence entre les égaux et la comparaison de Bigdecimal en Java est tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.