Java的无声杀手–整数溢出，小心！

Myth丶恋晨 2023-02-15 07:50 4阅读 0赞

信不信由你，Java也包含Integer缓冲区溢出。 我不确定这是否是描述它的正确词，也许您可以建议一些

OK，请看下面的程序，该程序每天打印微秒数。

public class JavaLongOverflow {
    
        public static void main(String[] args) {
    
            final long MICROS_PER_DAY = 24 * 60 * 60 * 1000 * 1000;
    
            System.out.println("MICROS_PER_DAY : " + MICROS_PER_DAY);
           
        }
    
    }

## 结果 ##

MICROS_PER_DAY : 500654080

哦..答案是**500654080** 。 等待..答案正确吗？ 正确的答案应该是**864亿** ！ 为什么Java会给我不准确的结果？ 这个数字是哪里来的？ 到底发生了什么事？

我确实认为这是由“ int”溢出引起的。 是的，“ long MICROS\_PER\_DAY”变量具有足够的空间来容纳像86400000000这样的大数字，但它不适合“ int”！ “ int”的最大数目为2147483647。仔细阅读上面的程序，整个算法在“ int”中，结果提升为long并分配给“ long MICROS\_PER\_DAY”变量。 **根据\[JLS 5.1.2\]，从int到long的提升被引用为扩大原始转换，保留了（错误的）数值。**

但是，我们可以通过在第一个整数中显式表示“ long”来避免整个无声杀手溢出，从而迫使整个运算成为一个长算法。

public class JavaLongOverflow {
    
        public static void main(String[] args) {
    
            final long MICROS_PER_DAY = 24L * 60 * 60 * 1000 * 1000;
    
            System.out.println("MICROS_PER_DAY : " + MICROS_PER_DAY);
           
        }
    
    }

## 结果 ##

MICROS_PER_DAY : 86400000000

上面的程序按预期打印86400000000

## 结论 ##

这个错误是如此难以检测或察觉。 有时甚至无法检测到它。 如果有人在金融系统中犯此类错误，我将无法想象结果。 我唯一的建议是在处理两种不同类型的原始类型时显式转换原始类型。 在任何计算中，始终避免自动扩大原始转换。

标签： [Java][] [技巧][Link 1]

> 翻译自: [https://mkyong.com/java/javas-silent-killer-buffer-overflow-careful/][https_mkyong.com_java_javas-silent-killer-buffer-overflow-careful]

[Java]: https://mkyong.com/tag/java/
[Link 1]: https://mkyong.com/tag/tips/
[https_mkyong.com_java_javas-silent-killer-buffer-overflow-careful]: https://mkyong.com/java/javas-silent-killer-buffer-overflow-careful/