为什么'（int）（char）（byte）-2'在Java中产生65534？

Question

我在工作的技术测试中遇到了这个问题。给出以下代码示例：

public class Manager {
    public static void main (String args[]) {
        System.out.println((int) (char) (byte) -2);
    }
}

输出为65534。

此行为仅显示负值。0和正数产生相同的值，表示在SOP中输入的那个。此处的字节无关紧要；我尝试过没有它。

所以我的问题是：这到底是怎么回事？

Answer 1

在您了解这里发生的事情之前，我们需要达成一些先决条件。了解以下要点后，剩下的就是简单的推论：

1. JVM中的所有原始类型都表示为一系列位。的int类型是由32位，所表示char和short类型由16位和byte类型由8位表示。

2. 所有JVM号都是带符号的，其中char类型是唯一的无符号“数字”。对数字进行签名时， 最高 位用于表示该数字的符号。对于此最高位，0代表一个非负数（正数或零），1代表一个负数。同样，对于带正负号的数字，负值将被 反转 为正数的递增顺序（技术上称为二进制补码表示法）。例如，正值byte以位表示，如下所示：

   00 00 00 00 => (byte) 0
   

   00 00 00 01 => (byte) 1
   00 00 00 10 => (byte) 2
   …
   01 11 11 11 => (byte) Byte.MAX_VALUE
   
   
   

负数的位顺序相反：

    11 11 11 11 => (byte) -1
11 11 11 10 => (byte) -2
11 11 11 01 => (byte) -3
...
10 00 00 00 => (byte) Byte.MIN_VALUE

这种反向表示法还解释了为什么负范围可以容纳一个额外的数字，而正范围包括其中的数字表示0。请记住，所有这些仅是 解释
位模式的问题。您可以以不同的方式记下负数，但是负数的这种反转表示法非常方便，因为它允许进行一些相当快速的转换，我们稍后将在一个小示例中看到。

如前所述，这不适用于该char类型。该char类型表示Unicode字符，其非负“数值范围”为0to
65535。每个数字都引用一个16位Unicode值。

1. 当之间进行转换int，byte，short，char和boolean类型的JVM需要添加或截比特。

如果目标类型由比其转换的类型更多的位来表示，那么JVM会简单地用给定值的最高位（代表签名）的值来填充其他插槽：

    |     short   |     byte    |
|             | 00 00 00 01 | => (byte) 1
| 00 00 00 00 | 00 00 00 01 | => (short) 1

得益于倒数符号，该策略也适用于负数：

    |     short   |     byte    |
|             | 11 11 11 11 | => (byte) -1
| 11 11 11 11 | 11 11 11 11 | => (short) -1

这样，将保留值的符号。在不赘述为JVM实现此操作的细节的情况下，请注意，此模型允许通过便宜的shift操作执行转换，这显然是有利的。

如前所述，该规则的一个例外是 扩展 了一个char无符号类型。由于我们说没有符号，因此也不需要反转符号，因此总是通过用填充附加位来应用 从
a进行的转换。的A转换到因此被执行为：char``0``char``int

    |            int            |    char     |     byte    |
|                           | 11 11 11 11 | 11 11 11 11 | => (char) \uFFFF
| 00 00 00 00 | 00 00 00 00 | 11 11 11 11 | 11 11 11 11 | => (int) 65535

当原始类型的位数多于目标类型的位数时，仅会切断附加位。只要原始值适合目标值，就可以正常工作，例如short将a 转换为a的情况如下byte：

    |     short   |     byte    |
| 00 00 00 00 | 00 00 00 01 | => (short) 1
|             | 00 00 00 01 | => (byte) 1
| 11 11 11 11 | 11 11 11 11 | => (short) -1
|             | 11 11 11 11 | => (byte) -1

但是，如果值 太大 或 太小 ，将不再起作用：

    |     short   |     byte    |
| 00 00 00 01 | 00 00 00 01 | => (short) 257
|             | 00 00 00 01 | => (byte) 1
| 11 11 11 11 | 00 00 00 00 | => (short) -32512
|             | 00 00 00 00 | => (byte) 0

这就是为什么缩小铸件有时会导致奇怪的结果的原因。您可能想知道为什么以这种方式实现缩小。您可能会争辩说，如果JVM检查一个数字的范围，而是将一个不兼容的数字转换为相同符号的最大可表示值，它将更加直观。但是，这将需要分支，这是一项昂贵的操作。这一点特别重要，因为这两个的补码表示法允许廉价的算术运算。

有了所有这些信息，我们可以看到-2您的示例中的数字发生了什么：

|           int           |    char     |     byte    |
| 11 11 11 11 11 11 11 11 | 11 11 11 11 | 11 11 11 10 | => (int) -2
|                         |             | 11 11 11 10 | => (byte) -2
|                         | 11 11 11 11 | 11 11 11 10 | => (char) \uFFFE
| 00 00 00 00 00 00 00 00 | 11 11 11 11 | 11 11 11 10 | => (int) 65534

如您所见，byte强制转换是多余的，因为对的强制转换char会削减相同的位。

如果您更喜欢所有这些规则的正式定义，那么JVMS也可以指定所有这些。

最后一点：类型的位大小不一定代表JVM为在其内存中表示该类型而保留的位数。作为事实上，在JVM不区分之间boolean，byte，short，char和int类型。它们全部由相同的JVM类型表示，其中虚拟机仅模拟这些转换。在方法的操作数堆栈（即方法中的任何变量）上，所有已命名类型的值都占用32位。但是，对于任何JVM实现者都可以随意处理的数组和对象字段，情况并非如此。