Hehe, tò mò. Tôi nghĩ rằng đây là một "lỗi có chủ đích", có thể nói như vậy.
Lý do cơ bản là cách lớp Integer được viết. Về cơ bản, parseInt được "tối ưu hóa" cho các số dương. Khi phân tích cú pháp chuỗi, nó xây dựng kết quả một cách tích lũy, nhưng bị phủ định. Sau đó, nó lật dấu hiệu của kết quả cuối cùng.
Thí dụ:
66 = 0x42
phân tích cú pháp như:
4*(-1) = -4
-4 * 16 = -64 (hex 4 parsed)
-64 - 2 = -66 (hex 2 parsed)
return -66 * (-1) = 66
Bây giờ, hãy xem ví dụ FFFF8000 của bạn
16*(-1) = -16 (first F parsed)
-16*16 = -256
-256 - 16 = -272 (second F parsed)
-272 * 16 = -4352
-4352 - 16 = -4368 (third F parsed)
-4352 * 16 = -69888
-69888 - 16 = -69904 (forth F parsed)
-69904 * 16 = -1118464
-1118464 - 8 = -1118472 (8 parsed)
-1118464 * 16 = -17895552
-17895552 - 0 = -17895552 (first 0 parsed)
Here it blows up since -17895552 < -Integer.MAX_VALUE / 16 (-134217728).
Attempting to execute the next logical step in the chain (-17895552 * 16)
would cause an integer overflow error.
Chỉnh sửa (bổ sung): để parseInt () hoạt động "nhất quán" cho -Integer.MAX_VALUE <= n <= Integer.MAX_VALUE, chúng sẽ phải triển khai logic để "xoay" khi đạt tới -Integer.MAX_VALUE trong kết quả tích lũy, bắt đầu lại ở cuối tối đa của dải số nguyên và tiếp tục xuống dưới từ đó. Tại sao họ không làm điều này, người ta sẽ phải hỏi Josh Bloch hoặc bất cứ ai thực hiện nó ngay từ đầu. Nó có thể chỉ là một sự tối ưu hóa.
Tuy nhiên,
Hex=Integer.toHexString(Integer.MAX_VALUE);
System.out.println(Hex);
System.out.println(Integer.parseInt(Hex.toUpperCase(), 16));
hoạt động tốt, chỉ vì lý do này. Trong sourcee cho Integer, bạn có thể tìm thấy nhận xét này.