标签：instance 导致 ring put cache lse 比较大小 else this
先想一下，创建BigDecimal对象的时候一般是怎么创建的？
作为一个数字类型，经常有的操作是比较大小，有一种情况是比较是否相等。用equal方法还是compareTo方法？这里就是一个大坑
1 //new 传进去一个double 2 BigDecimal newZero = new BigDecimal(0.0); 3 System.out.println(BigDecimal.ZERO.equals(newZero)); 4 5 //new 传进去一个字符串 6 BigDecimal stringNewZero = new BigDecimal("0.0"); 7 System.out.println(BigDecimal.ZERO.equals(stringNewZero)); 8 9 //valueOf 传进去一个double 10 BigDecimal noScaleZero = BigDecimal.valueOf(0.0); 11 System.out.println(BigDecimal.ZERO.equals(noScaleZero)); 12 13 //valueOf 传进去一个double，再手动设置精度为1 14 BigDecimal scaleZero = BigDecimal.valueOf(0.0).setScale(1); 15 System.out.println(BigDecimal.ZERO.equals(scaleZero));
用于比较的值全都是0，猜一猜上面几个equals方法返回的结果是什么？全都是true？no no no...
true false false false
惊不惊喜，意不意外？原因是什么呢？看一下BigDecimal的equals方法的实现：
1 public boolean equals(Object x) { 2 //类型不同，直接返回false 3 if (!(x instanceof BigDecimal)) 4 return false; 5 BigDecimal xDec = (BigDecimal) x; 6 //同一个对象，直接返回true 7 if (x == this) 8 return true; 9 //精度不同，直接返回false！！ 10 if (scale != xDec.scale) 11 return false; 12 long s = this.intCompact; 13 long xs = xDec.intCompact; 14 if (s != INFLATED) { 15 if (xs == INFLATED) 16 xs = compactValFor(xDec.intVal); 17 return xs == s; 18 } else if (xs != INFLATED) 19 return xs == compactValFor(this.intVal); 20 21 return this.inflated().equals(xDec.inflated()); 22 }
从前面三个简单的判断就可以看出来，debug跟一下就知道是上面equals方法有三个返回false，都是因为精度不同。那么BigDecimal.ZERO的精度是多少呢？看下源码：
1 // Cache of common small BigDecimal values. 2 private static final BigDecimal zeroThroughTen[] = { 3 new BigDecimal(BigInteger.ZERO, 0, 0, 1), 4 new BigDecimal(BigInteger.ONE, 1, 0, 1), 5 new BigDecimal(BigInteger.valueOf(2), 2, 0, 1), 6 new BigDecimal(BigInteger.valueOf(3), 3, 0, 1), 7 new BigDecimal(BigInteger.valueOf(4), 4, 0, 1), 8 new BigDecimal(BigInteger.valueOf(5), 5, 0, 1), 9 new BigDecimal(BigInteger.valueOf(6), 6, 0, 1), 10 new BigDecimal(BigInteger.valueOf(7), 7, 0, 1), 11 new BigDecimal(BigInteger.valueOf(8), 8, 0, 1), 12 new BigDecimal(BigInteger.valueOf(9), 9, 0, 1), 13 new BigDecimal(BigInteger.TEN, 10, 0, 2), 14 }; 15 16 17 /** 18 * The value 0, with a scale of 0. 19 * 20 * @since 1.5 21 */ 22 public static final BigDecimal ZERO = zeroThroughTen[0];
BigDecimal.ZERO值为0，精度为0.
而上面几种返回false的case，都是因为精度不同。精度不同的原因，则是BigDecimal对象初始化的方式不同,从源码上看，前三种初始化的方式都不同。
所以说，BigDecimal比较大小，还是用compareTo方法比较靠谱，改为compareTo之后，上面四个case返回的结果都是相等：
1 BigDecimal newZero = new BigDecimal(0.0); 2 System.out.println(BigDecimal.ZERO.compareTo(newZero)); 3 4 BigDecimal stringNewZero = new BigDecimal("0.0"); 5 System.out.println(BigDecimal.ZERO.compareTo(stringNewZero)); 6 7 BigDecimal noScaleZero = BigDecimal.valueOf(0.0); 8 System.out.println(BigDecimal.ZERO.compareTo(noScaleZero)); 9 10 BigDecimal scaleZero = BigDecimal.valueOf(0.0).setScale(1); 11 System.out.println(BigDecimal.ZERO.compareTo(scaleZero));
输出结果
0 0 0 0
由此联想到的一个更大的坑是，如果将BigDecimal的值作为HashMap的key，因为精度的问题，相同的值就可能出现hashCode值不同并且equals方法返回false，导致put和get就很可能会出现相同的值但是存取了不同的value。
再想一想，小数类型在计算机中本来就不能精确存储，再把其作为HashMap的key就相当不靠谱了，以后还是少用。
另外需要注意的一点是，写代码调别人写的方法时，最好是点进去看一下实现。再小再常用的方法，都可能埋着大坑
标签：instance 导致 ring put cache lse 比较大小 else this
原文地址：https://www.cnblogs.com/z941030/p/9639717.html
