为什么BigDecimal自然排序与equals不一致？

Question

来自JavadocBigDecimal:

注:如果应谨慎BigDecimal对象作为一个键SortedMap或元素的SortedSet自BigDecimal的自然顺序是与等号一致.

例如,如果你创建HashSet并添加new BigDecimal("1.0")和new BigDecimal("1.00")它的集将包含两个元素(因为该值有不同的尺度,所以是不相等的根据equals和hashCode),但如果你有做同样的事情TreeSet,该Set只包含一个元素,因为使用时值比较相等compareTo.

这种不一致背后有什么具体原因吗？

Answer 1

从BigDecimal 的OpenJDK实现:

/**
     * Compares this {@code BigDecimal} with the specified
     * {@code Object} for equality.  Unlike {@link
     * #compareTo(BigDecimal) compareTo}, this method considers two
     * {@code BigDecimal} objects equal only if they are equal in
     * value and scale (thus 2.0 is not equal to 2.00 when compared by
     * this method).
     *
     * @param  x {@code Object} to which this {@code BigDecimal} is 
     *         to be compared.
     * @return {@code true} if and only if the specified {@code Object} is a
     *         {@code BigDecimal} whose value and scale are equal to this 
     *         {@code BigDecimal}'s.
     * @see    #compareTo(java.math.BigDecimal)
     * @see    #hashCode
     */
    @Override
    public boolean equals(Object x) {
        if (!(x instanceof BigDecimal))
            return false;
        BigDecimal xDec = (BigDecimal) x;
        if (x == this)
            return true;
    if (scale != xDec.scale)
        return false;
        long s = this.intCompact;
        long xs = xDec.intCompact;
        if (s != INFLATED) {
            if (xs == INFLATED)
                xs = compactValFor(xDec.intVal);
            return xs == s;
        } else if (xs != INFLATED)
            return xs == compactValFor(this.intVal);

        return this.inflate().equals(xDec.inflate());
    }

更多来自实施:

 * <p>Since the same numerical value can have different
 * representations (with different scales), the rules of arithmetic
 * and rounding must specify both the numerical result and the scale
 * used in the result's representation.

这就是为什么执行equals需要scale考虑.将字符串作为参数的构造函数实现如下:

    public BigDecimal(String val) {
        this(val.toCharArray(), 0, val.length());
    }

其中第三参数将被用于scale(在另一个构造函数)这就是为什么串1.0和1.00将创建不同BigDecimals的(具有不同的尺度).

来自Effective Java作者:Joshua Bloch:

compareTo契约的最后一段是一个强烈的建议,而不是一个真正的规定,只是说明compareTo方法所施加的相等测试通常应该返回与equals方法相同的结果.如果遵守此规定,则compareTo方法强加的顺序与equals一致.如果它被违反,则说明顺序与equals不一致.compareTo方法强加与equals不一致的顺序的类仍然有效,但包含该类元素的有序集合可能不遵守相应集合接口(Collection,Set或Map)的常规协定.这是因为这些接口的一般契约是用equals方法定义的,但是已排序的集合使用compareTo强加的相等性测试来代替equals.如果发生这种情况,这不是灾难,但需要注意的是.