JDK 6中的源代码:

public static long round(double a) {
    return (long)Math.floor(a + 0.5d);
}

JDK 7中的源代码:

public static long round(double a) {
    if (a != 0x1.fffffffffffffp-2) {
        // a is not the greatest double value less than 0.5
        return (long)Math.floor(a + 0.5d);
    } else {
        return 0;
    }
}

当值为0.4999999999999999994d时，在JDK 6中，它将调用floor，因此返回1，但在JDK 7中，if条件是检查该数字是否是小于0.5的最大双精度值。在本例中，该数字不是小于0.5的最大双精度值，因此else块返回0。

您可以尝试0.49999999999999999d，它将返回1，但不会返回0，因为这是小于0.5的最大双精度值。

JDK 6中的源代码:

public static long round(double a) {
    return (long)Math.floor(a + 0.5d);
}

JDK 7中的源代码:

public static long round(double a) {
    if (a != 0x1.fffffffffffffp-2) {
        // a is not the greatest double value less than 0.5
        return (long)Math.floor(a + 0.5d);
    } else {
        return 0;
    }
}

当值为0.4999999999999999994d时，在JDK 6中，它将调用floor，因此返回1，但在JDK 7中，if条件是检查该数字是否是小于0.5的最大双精度值。在本例中，该数字不是小于0.5的最大双精度值，因此else块返回0。

您可以尝试0.49999999999999999d，它将返回1，但不会返回0，因为这是小于0.5的最大双精度值。

这似乎是一个已知的错误(Java错误6430675:Math。round有令人惊讶的行为0x1.fffffffffffffp-2)，这已在Java 7中修复。

总结

在Java 6(可能更早)中，round(x)被实现为floor(x+0.5).1这是一个规范错误，恰恰针对这一病理情况Java 7不再强制执行这个破碎的实现

这个问题

0.5+ 0.4999999999999999994正好是1的双精度:

static void print(double d) {
    System.out.printf("%016x\n", Double.doubleToLongBits(d));
}

public static void main(String args[]) {
    double a = 0.5;
    double b = 0.49999999999999994;

    print(a);      // 3fe0000000000000
    print(b);      // 3fdfffffffffffff
    print(a+b);    // 3ff0000000000000
    print(1.0);    // 3ff0000000000000
}

这是因为0.4999999999999999994的指数小于0.5，所以当它们相加时，它的尾数会移位，ULP会变大。

解决方案

从Java 7开始，OpenJDK(例如)是这样实现的

public static long round(double a) {
    if (a != 0x1.fffffffffffffp-2) // greatest double value less than 0.5
        return (long)floor(a + 0.5d);
    else
        return 0;
}

1. http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html#round%28double%29

2. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6430675(感谢@SimonNickerson找到这个)

3. http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#round%28double%29

4. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/lang/Math.java#Math.round%28double% 29

我在JDK 1.6 32位上得到了相同的结果，但在Java 7 64位上，我为0.4999999999999999994得到了0，四舍五入为0，最后一行不打印。这似乎是一个虚拟机问题，但是，使用浮点，您应该期望在不同的环境(CPU, 32位或64位模式)上的结果有所不同。

而且，当使用整数或逆矩阵等时，这些位可以产生巨大的差异。

x64输出:

10.5 rounded is 11
10.499999999999998 rounded is 10
9.5 rounded is 10
9.499999999999998 rounded is 9
8.5 rounded is 9
8.499999999999998 rounded is 8
7.5 rounded is 8
7.499999999999999 rounded is 7
6.5 rounded is 7
6.499999999999999 rounded is 6
5.5 rounded is 6
5.499999999999999 rounded is 5
4.5 rounded is 5
4.499999999999999 rounded is 4
3.5 rounded is 4
3.4999999999999996 rounded is 3
2.5 rounded is 3
2.4999999999999996 rounded is 2
1.5 rounded is 2
1.4999999999999998 rounded is 1
0.5 rounded is 1
0.49999999999999994 rounded is 0

下面的答案摘自Oracle bug报告6430675。请访问报告以获得完整的解释。

方法{Math, StrictMath。轮在操作上定义为

(long)Math.floor(a + 0.5d)

对于双重论证。虽然这个定义通常如预期的那样工作，但对于0x1，它给出了令人惊讶的结果1，而不是0。fffffffffffffp-2(0.49999999999999994)。

值0.4999999999999999994是小于0.5的最大浮点值。作为十六进制浮点字面值，它的值是0x1。fffffffffffp-2，等于(2 -2 ^52)* 2^ 2。==(0.5 - 2^54)。因此，和的准确值

(0.5 - 2^54) + 0.5

是1 - 2^54。这是两个相邻浮点数(1 - 2^53)和1之间的中间值。在Java使用的IEEE 754算术舍入到最接近偶数舍入模式中，当一个浮点结果不精确时，必须返回两个可表示的浮点值中包含精确结果的较近的一个;如果两个值相等接近，则返回最后一位为0的值。在这种情况下，add的正确返回值是1，而不是小于1的最大值。

虽然方法是按定义操作的，但这个输入的行为是非常令人惊讶的;规范可以修改为“四舍五入到最接近的长，四舍五入绑定”，这将允许更改此输入的行为。