意外的无限字节 for 循环
我有以下循环:
for (byte i = 0 ; i < 128; i++) {
System.out.println(i + 1 + " " + name);
}
当我执行程序时,它会在无限循环中打印从 -128 到 127 的所有数字。为什么会出现这种情况?
I have the following loop:
for (byte i = 0 ; i < 128; i++) {
System.out.println(i + 1 + " " + name);
}
When I execute my programm it prints all numbers from -128 to 127 in an infinite loop. Why does this happen?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
byte 是 1 字节类型,因此可以在 -128...127 之间变化,因此条件 i < 128 始终为真。当你将 1 加到 127 时,它会溢出并变成 -128,依此类推(无限)循环......
byte is a 1-byte type so can vary between -128...127, so condition i < 128 is always true. When you add 1 to 127 it overflows and becomes -128 and so on in a (infinite) loop...
127之后,当它递增时,它将变成-128,所以你的条件将不匹配。
它的工作方式如下:
8 位可以表示最多 127 个有符号数字。
请参阅 此处了解原始数据类型。
图片胜于雄辩
After 127, when it increments, it will become -128, so your condition won't match .
It will work like this:
as 8 bits can represent a signed number up to 127.
See here for the primitive data types.
Picture says more than words
因为字节在 Java 中是有符号的,所以它们总是小于 128。
为什么 Java 选择有符号字节是一个从古至今的谜团。我一直无法理解为什么他们破坏了一个完美的无符号数据类型:-)
试试这个:
或者,更好的是:
Because bytes are signed in Java so they will always be less than 128.
Why Java chose signed bytes is a mystery from the depths of time. I've never been able to understand why they corrupted a perfectly good unsigned data type :-)
Try this instead:
or, better yet:
因为当 i == 127 并且执行 i++ 时,它会溢出到 -128。
because when i == 127 and and you executes i++ it overflows to -128.
类型字节的范围为-128..127。所以
i
总是小于128。The type byte has a range of -128..127. So
i
is always less than 128.好吧,这背后的原因已经得到解答,但如果您对一些背景感兴趣:
位
是计算机可以识别的最小存储单位(注意不是最小的数字)。位要么是0
,要么是1
。字节
是一种8位数据类型,这意味着它由8位字符串组成,例如10101010
或0001110
。使用简单的组合,我们知道有2^8 = 256
可能的字节组合。如果我们只想表示正数,我们可以直接从基数 2 转换为基数 10。工作方式是,对于位字符串
b7b6b5b4b3b2b1b0
,十进制数为dec = (bn * 2^n) 的 n=0 到 7 的总和。
通过仅表示正数(
无符号字节
),我们可以表示0
到255
(含)范围内的 256 个可能的数字。当我们想要表示签名数据时,问题就出现了。一种简单的方法(注意,这是用于背景,而不是 java 的方式)是取最左边的位并将其设为符号位,其中
1
为负数,0
是积极的。例如,00010110
将是21
,10010110
将是-21
。这种系统有两个主要问题。首先是
00000000
是0
,10000000
是-0
,但是众所周知,没有< code>-0 与0
有所不同,但这样的系统允许数字和0 ≠ -0
。第二个问题是,由于表示两个零,系统只允许表示-127
到127
之间的数字,范围只有254
(比以前少2
)。一种更好的系统(也是大多数系统使用的系统)称为Two's Compliment。在二进制补码中,正数用其正常位串表示,其中最左边的位为 0。负数用最左边的位表示为 1,然后计算该数字的二进制补码(系统由此得名) )
虽然从数学上来说这是一个稍微复杂的过程,但因为我们正在处理数字
2
,所以有一些捷径。本质上,您可以采用正数版本并(从右到左)取所有零,直到达到 1。复制这些零和一,然后取其余位的NOT
。例如,要得到-21
,正21
是00010110
,我们采用10
而不是其余的得到11101010
,-21
的两个补码表示。Two's Compliment 是一个更难掌握的系统,但它避免了前面提到的问题,并且 n 位数字可以表示从
-2^(n-1)
到的所有数字2^(n-1)-1
对于我们的字节来说意味着-128
到127
(因此这个问题中存在问题)一些注意事项:< br>
- 这仅适用于整数表示。实数表示完全是另一个系统(如果有要求,我相信我们可以在 CW 帖子中制作数字表示)
- 如果您有兴趣,维基百科还有更多数字表示系统。
Alright, so the reason behind this has been answered already, but in case you were interested in some background:
A
bit
is the smallest unit of storage which the computer can recognize (n.b. not the smallest number). A bit is either a0
or a1
.A
byte
is an 8 bit data type, meaning it is composed of 8 bit strings such as10101010
or0001110
. Using simple combinatorics, we know that there are2^8 = 256
possible combinations of bytes.If we wanted to only represent positive numbers, we could do a straight conversion from base 2 to base 10. The way that works is, for a bit string
b7b6b5b4b3b2b1b0
the number in decimal isdec = sum from n=0 to 7 of (bn * 2^n)
.By only representing positive numbers ( an
unsigned byte
) we can represent 256 possible numbers in the range0
to255
inclusive.The problem comes in when we want to represent signed data. A naive approach (n.b. this is for background, not the way java does it) is to take the left most bit and make it the sign bit where
1
is negative and0
is positive. So for example00010110
would be21
and10010110
would be-21
.There are two major problems with such a system. The first is that
00000000
is0
and10000000
is-0
, but as everyone knows, there is no-0
that is somehow different from0
, but such a system allows for the number and0 ≠ -0
. The second problem is that, due to representing two zeroes, the system only allows for representing numbers from-127
to127
, a range of only254
(2
less than before).A much better system (and the one which most systems use) is called Two's Compliment. In Two's Compliment, the positive numbers are represented with their normal bit string where the leftmost bit is 0. Negative numbers are represented with the left most bit as a 1 and then calculating the two's compliment for that number (from whence the system gets its name)
Although mathematically it is a slightly more complex process, because we are dealing with the number
2
there are some short cuts. Essentially, you can take the positive version and (from right to left) take all zeroes until you hit a 1. Copy those zeroes and one, then take theNOT
of the rest of the bits. So for example, to get-21
, positive21
is00010110
we take the10
and not the rest to get11101010
, the two's compliment representation of-21
.Two's Compliment is a much more difficult system to grasp, but it avoids the previously stated problems, and for an n-bit number can represent all digits from
-2^(n-1)
to2^(n-1)-1
which for our byte means-128
to127
(hence the problem in this question)A couple of notes:
- This is for integer representation only. Real number representation is another system entirely (if there is a request for it, I'm sure we could make a number representation CW post)
- Wikipedia has a couple more number representation systems if you're interested.
最好的是如果你这样做
Best is if you do
这应该有效
this should work