为什么要施放一个很大的长量int给我们带来一个奇怪的输出（Java）？

Question

我在爪哇练习一些铸件，并且面临着一个我在任何地方找不到任何答案的情况。有很多类似的问题带有答案，但是没有一个给我解释了这种特殊情况。

当我做类似

    long l = 165787121844687L;
    int i = (int) l;

    System.out.println("long: " + l);
    System.out.println("after casting to int: " + i);

输出的事情时，

long: 165787121844687
after casting to int: 1384219087

这个结果对我来说非常有趣。

我知道 long 的类型是64位整数， int 类型是32位整数。我还知道，当我们将较大类型的类型投入到较小的类型时，我们可能会丢失信息。而且我知道有一个非常有用的 Math.tointexact（）方法。

但是，对此“ 1384219087 ”的解释是什么？数据丢失，但是为什么这个数字呢？如何“ 165787121844687 ”成为“ 1384219087 ”？为什么代码甚至编译？

就是这样。谢谢！

Answer 1

十六进制符号中的16578712184687L = 0000 96C8 5281 81CF

1384219087在六角符号中= 5281 81CF，

因此，铸件截断了预期的前32位。

                        32-bits 
                        deleted 
                       ▼▼▼▼ ▼▼▼▼
165_787_121_844_687L = 0000 96C8 5281 81CF  ➣  1_384_219_087
    64-bit long                  ▲▲▲▲ ▲▲▲▲      32-bit int 
                                  32-bits 
                                 remaining

Answer 2

如果您将这两个数字转换为十六进制，您会

96C8528181CF
528181CF

看到这里发生了什么？

Answer 3

OldProgrammer的答案是正确的，应接受。这是一些其他信息，还有解决方法。

Java规格说这是如此

为什么代码甚至编译？

当您在Java中投放数字原始性时，您对结果负责，包括信息丢失的风险。

为什么？因为Java规格是这样说的。总是最好阅读文档。直觉编程是有风险的业务。

请参阅 java语言规范 href =“ https://docs.oracle.com/javase/specs/jls/se18/html/jls-5.html#jls-5.1.3” rel =“ nofollow noreferrer”> 5.1.3。缩小原始转换 。引用（强调我的）：

狭窄的原始转换可能会丢失信息…

将签名整数转换为整数t的狭窄转换，简单地丢弃了除n最低订单位以外的所有内容，其中n是代表T类型T的位数。除了可能关于数值的大小的信息丢失，这可能导致结果值的符号与输入值的符号不同。

数学＃…精确…

想在从long转换为简短，使用数学 精确的方法。如果操作溢出，则执行。您可以陷入此例外。

try 
{
   int i = Math.toIntExact( 165_787_121_844_687L ) ;  // Convert from a `long` to an `int`. 
} 
catch ( ArithmeticException e ) 
{ 
    // … handle conversion operation overflowing an `int` …
}

您会发现类似的数学＃…精确…绝对值，加法，减少，增加，乘以，负和减法的方法。