Java 长%int是否总是适合整数

有人能证实这是真的吗

Java将把

long

%

int

转换为

long

值。但是，它永远不能大于模数，将其转换为

int

总是安全的

long a = 
int b =
int c = (int) (a % b); // cast is always safe.

类似地，

long

%

short

也可以安全地转换为

short

如果是真的，有人知道为什么Java的

%

类型比需要的长吗

此外，对于

long

&

int

（如果忽略符号扩展名）

它总是安全的！（我对数学很满意。）

mod运算的结果总是小于除数。由于mod运算的结果本质上是执行整除后的余数，因此余数永远不会大于除数

---

我怀疑让操作返回一个

long

的原因是因为除数在操作发生之前被扩展为

long

。这使得

long

结果成为可能。（注意，即使变量在内存中展开，其值也不会改变。展开的

int

永远不会大于

int

所能容纳的值。）

正如Marc B所提到的，Java将在实际执行

%

操作之前将

B

提升为

长
。这项推广适用于所有算术运算，甚至我相信是

换句话说，如果您有一个二进制运算，并且两个参数的类型不相同，则较小的参数将被提升，以便两侧都具有相同的类型。
对于大多数（如果不是全部）算术运算，Java将假定您需要最大定义精度。想象一下，如果你这样做：

long a = ...;
int b = ...;

long c = a % b + Integer.MAX_VALUE;

如果Java自动将
a%b
向下转换为
int
，则上述代码将导致
int
溢出，而不是将
c
设置为完全合理的
long
值

这与使用
double
和
int
执行操作将产生
double
的原因相同。将最不准确的值向上转换为更准确的值更安全。然后，如果程序员知道的比编译器多，并且想要向下转换，那么他可以显式地执行

更新
另外，在详细考虑了这一点之后，我猜大多数CPU架构都没有结合32位和64位值的操作。因此，需要将32位值提升为64位值，以便将其用作CPU的mod操作的参数，并且该操作的结果本机为64位值。向下转换为
int
将添加一个操作，这会影响性能。将这一事实与您实际上可能希望为其他操作保留一个
long
值的想法结合起来（正如我上面提到的），将结果强制为
int
是没有意义的，除非开发人员明确希望它是一个值

有人知道为什么Java的%类型比需要的长吗

我不确定。也许是为了让它与其他乘法运算符的工作方式完全相同：
*
和
\
。在
中，乘法表达式的类型是其操作数的提升类型。
向
long%int
添加一个异常将令人困惑。
这是一个后期插话，但原因很简单：

字节码操作数确实需要显式强制转换（
L2I
），而long需要2个堆栈位置，而int、char、short、byte需要1个堆栈位置[从字节强制转换到int不需要字节码指令]。mod操作后，结果在堆栈顶部占据2个位置

编辑：另外，我忘了提到Java没有64b/32b的除法/余数。只有64->64位操作，即
LDIV
和
LREM
b的值是1，变量a的值很长，那么结果将不适合int.@Cybernate，除法是这样，余数不是这样。如果
b
是
1
，则
a%b
始终是
0
@Cybernate，
x%1
始终是
0
，并且适合内部和
int
；）@Hennin：我的错..忽略并假设%as/：）对于“有人知道为什么Java的%类型比需要的长吗？”@Balus，oops。我错过了问题的那一部分。“这使得长结果成为可能。”这意味着它并不总是安全的？？？@Peter，不。将
int
扩展为
long
只会占用更多内存。它实际上不会增加价值。（同样适用于
short
或
byte
）@Peter，对不起，我不太清楚。执行mod by
int
时，结果将始终适合
int
的内部。所以，演员总是安全的。是的，但为什么？它似乎永远都不需要。我想它应该保持简单，并遵循您提到的规则，即使它不理想。位移位运算符的特殊之处在于两个操作数分别提升。这具有实际效果，例如，
1+1：到目前为止，对于为什么要这样做，对较长表达式所发生的事情是最好的解释。+1很好！一个nit:
b
应该是代码片段中的
int
，以匹配问题，但你的观点仍然成立；顶部32位是否只包含较低32位的符号，使其成为冗余？@Peter，即使是x86的IDIV 64b/32b也会返回商和EAX/EDX中的余数（两者都是32位寄存器）。我的意思是，很明显，除以n位大小的除数，结果可以达到n位大小。（还添加了一个编辑）