Java基本类型全解析：六种数字类型、radix进制转换与溢出避坑指南

1. 八种基本类型，一张表看清楚全貌

1.1 一张表看懂八种类型的字节、范围与默认值

Java语言提供了八种基本类型，这个答案我在面试里被问过无数次，也问过别人无数次。很多人在网上背答案：byte、short、int、long、float、double、char、boolean，张嘴就来，但往下追问"每种占几个字节""默认值是什么""为什么 float 比 long 大却不精确"，立刻就卡壳。所以这篇我不打算只给一个速查表，而是把每个数据类型的边界、底层理由和实际场景都拆开讲清楚，尤其是标题里提到的六种数字类型和基数（radix）问题。

先把最基础的表格放出来，这是后面所有讨论的底子：

第一行到最后一行都值得琢磨。byte 只占1个字节，所以它的取值范围是 -2^7 到 2^7-1，因为最高位要留给符号。int 是4字节，范围就是 -2^31 到 2^31-1。这个推导逻辑比死记硬背重要得多，因为一旦你懂得了"n 个字节有 n*8 位，去掉一位符号位"这个规律，任何环境下的整型范围都能自己算出来。

1.2 为什么偏偏是这八种，boolean和char又特殊在哪

很多人会问：为什么 Java 不干脆只留 int 和 double，搞这么多类型不是麻烦吗？这其实是经典的空间换灵活性的设计。Java 要跑在各种设备上，网络报文、文件头、嵌入式场景里一个字节一个字节地抠空间是常有的事。你用 byte 存一个状态码，一个数组能省下几倍的堆内存；你用 short 存端口号，也比 int 更贴切。类型越多，你在"够用"和"省空间"之间的选择就越精准。

boolean 在 JVM 规范里其实没有明确规定单个 boolean 占几个字节，HotSpot 的实现里通常单独使用占1个字节，boolean 数组里每个元素又可以按1位来优化。它不参与数值运算，不能直接强转成 int，这也是很多人写代码时容易踩的第一个坑。char 就更特殊了，它在 Java 里是16位无符号整数，存的是 Unicode 码元，所以 char 可以做算术运算：'A' + 1 结果是 66，也就是 'B'，但它本质上不是数字类型，不会出现在标题说的"六种数字类型"里。

这就引出标题里的关键定义了。六种数字类型指的是 byte、short、int、long、float、double，char 和 boolean 不算数字类型。char 虽然能参与运算，但它表达的是字符；boolean 干脆只有两个值。这个分类在《Java 语言规范》里写得很清楚，面试的时候把这个区分说清楚，比报菜名式地背八个类型要加分得多。

2. 六种数字类型：范围、精度与字面量写法

2.1 整数四兄弟的边界值推导

把六种数字类型分成两组来看就清爽了：一组是整数类型 byte、short、int、long，另一组是浮点类型 float、double。

整数类型全靠补码表示，范围的计算逻辑是一致的：byte 是1字节，8位，带符号时最高位是符号位，所以正数最大是 01111111，也就是127；负数最小是 10000000，也就是 -128，因为补码的10000000没有正数对应值。int 是4字节，最大值就是 0x7fffffff，也就是 2147483647，这个数字打代码的人一定要记住，后面讲溢出会反复用到。

long 的边界值更夸张：9223372036854775807。写的时候必须加后缀 L，不然编译器会认为这是个 int 字面量然后报"integer number too large"错误。类似的，float 字面量要加 f 或 F，不加会被当成 double，在某些情况下会引入精度问题。这类后缀问题看着小，实际项目里出现莫名其妙的编译失败，十有八九是字面量类型不匹配。

2.2 float和double的精度差异，为什么0.1算不清

float 占4字节，double 占8字节，但是 float 的数值范围反而比 long 大得多，原因是浮点数用一部分位存指数，一部分位存尾数。float 的结构是1位符号、8位指数、23位尾数；double 是1位符号、11位指数、52位尾数。指数位让它们能表示巨大的数，但尾数位的有限性决定了它们不可能精确表示所有小数。

最经典的例子就是：

float a = 0.1f; double b = 0.1; System.out.println(a); System.out.println(b);

0.1 在二进制里是一个无限循环小数，不管 float 还是 double 都只能存储它的近似值。float 的有效位数只有大概7位，double 大概15到16位，所以打印出来经常会看到 0.10000000149011612 这种丑数。这就是为什么做金额计算绝对不能碰 float 和 double。我在项目里见过同事用 double 算订单金额，最后对账差了九分钱，排查了半天就是精度问题。如果你要做精确十进制运算，要么用 long 存"分"，要么用 BigDecimal。

2.3 字面量里那些容易写错的后缀和前缀

Java 字面量有一些容易被忽略的规则，面试和实战里都是高频点。整数默认是 int 类型，超过 int 范围必须加 L；浮点默认是 double，想存成 float 必须加 F。十六进制前缀是 0x，二进制前缀是 0b（Java 7 开始支持），而八进制前缀只有一个 0。这个八进制前缀是个历史巨坑，比如int x = 010;你以为是10，其实它是八进制数，算出来是8。我刚入职时候就被这个坑过，读老代码看到 010 一时没反应过来。

Java 7 还允许数字字面量加下划线，比如int salary = 1_000_000;这纯粹是为了可读性，编译时会去掉。我建议所有超过四位的数字都这么写，尤其是金额、时间戳、端口号，能肉眼少看错很多位。但要注意下划线不能放在开头、结尾、小数点旁边，否则编译直接报错。

long userId = 100_000_000_001L; int port = 0x1F90; // 8080 的十六进制写法 int mask = 0b10101010; // 二进制掩码

3. 基数（radix）是什么，Java方法里为什么总带它

3.1 进制概念与radix参数的来源

标题里提到的"基数"，翻译成英文就是 radix，它跟"进制"是同一个东西。十进制的 radix 是10，二进制的 radix 是2，十六进制的 radix 是16。为什么 Java 的很多方法签名里出现 radix？因为同样一串数字字符串，在不同进制下含义完全不一样："101" 在二进制下是5，在十进制下是101，在十六进制下是257。方法必须知道你要按哪种进制去解析，否则没法工作。

我见过太多人只会用 Integer.parseInt("123")，也就是默认十进制，根本不知道这个方法还有一个重载版本接收 radix 参数。一旦需要解析二进制、八进制、十六进制的字符串，比如解析配置文件里的颜色值#FF0000或者权限掩码0777，没有 radix 概念就只能自己手工拼逻辑，又慢又容易错。

进制在真实系统里无处不在：MAC 地址是十六进制，颜色值是十六进制，文件权限经常用八进制表示，位图操作里全是二进制掩码。理解 radix 不只是为了应付面试，而是为了能读懂这些数据。

3.2 最常用的带radix的内置方法

Java 为基本类型的包装类提供了一整套"进制转换函数"，我最常用的是这几个：

// 字符串按指定进制解析成数值 int a = Integer.parseInt("1101", 2); // 13 int b = Integer.parseInt("ff", 16); // 255 long c = Long.parseLong("777", 8); // 511 // 数值按指定进制转成字符串 String s1 = Integer.toString(255, 16); // "ff" String s2 = Integer.toHexString(255); // "ff"，等价的快捷方法 String s3 = Integer.toBinaryString(13); // "1101" String s4 = Integer.toOctalString(8); // "10"

这里的 Integer.parseInt 和 Integer.toString 就是标题里"函数"那一面的核心。如果你把这两个方向的函数配合起来，就能够在任意进制之间来回切换：先 parse 成一个数，再 toString 成目标进制。

需要特别提醒的是，parseInt 对非法字符非常敏感。比如 Integer.parseInt("0x1A", 16) 会抛 NumberFormatException，因为规范不接受"0x"前缀，它只认后面的"1A"。我刚才自己也被这个绊过很多次，所以建议写一个安全解析工具，先 trim，再判断字符串是否为空，包一层 try-catch，不要在生产代码里裸调 parseInt。

4. 进制转换实战：从内置方法到手写算法

4.1 Integer.parseInt和toString的配合

实际项目里进制转换最常见的三个场景：把十六进制颜色字符串解析成 RGB 分量、把 IP 和端口拼成十六进制报文、把数字转成短字符串用于邀请码或分享码。

第一个场景的代码长这样：

String color = "FF8800"; int value = Integer.parseInt(color, 16); int red = (value >> 16) & 0xFF; int green = (value >> 8) & 0xFF; int blue = value & 0xFF;

这个例子里同时用到了 radix 解析和位运算。先把"FF8800"按16进制解析成整数 16744448，再右移和掩码把三个字节拆出来。颜色值本身就是 base16 的数字，用 radix 参数直接解析比每次手动 charAt 去转字母要干净得多。

第二个场景很多人会写一个通用的"十进制转 N 进制"工具。其实内置的 Long.toString(long, int) 已经能处理 radix 在 2 到 36 之间的转换。它之所以上限到36，是因为 0-9 加 26 个英文字母正好够用。超过36就只能自己扩展字符集，比如再加大小写字母和特殊符号。

4.2 手写一个"除基取余"的通用转换器

虽然内置方法够用，但为了理解 radix 的本质，我建议每个 Java 开发者都手写一次除基取余的转换过程。原理很简单：一个数 N 转成 base 进制的字符串，就是不断用 N 除以 base，取余数，直到商为0，再把余数倒序排列。

public static String toBaseString(long num, int radix) { if (num == 0) { return "0"; } char[] digits = "0123456789abcdefghijklmnopqrstuvwxyz".toCharArray(); StringBuilder sb = new StringBuilder(); boolean negative = num < 0; long value = negative ? -num : num; while (value > 0) { sb.append(digits[(int) (value % radix)]); value /= radix; } if (negative) { sb.append('-'); } return sb.reverse().toString(); }

这段代码里最容易出错的就是负数处理。因为 Long.MIN_VALUE 的绝对值比 Long.MAX_VALUE 大1，直接-num会溢出，我这版只是演示思路，生产环境要小心。另一个坑是反转向量的时机，余数是从低位到高位生成的，最后必须 reverse 一次，我见过不少人漏掉这个后拿到的结果完全不对。

反过来，解析一个任意进制的字符串也可以用相同的数学思路：

public static long parseBase(String s, int radix) { long result = 0; for (int i = 0; i < s.length(); i++) { char c = s.charAt(i); int digit = Character.digit(c, radix); if (digit < 0) { throw new NumberFormatException("非法字符: " + c); } result = result * radix + digit; } return result; }

这里的核心是霍纳规则：每一项都乘以 radix 再加上当前位的数字。Character.digit 是另一个容易被忽略的宝藏函数，它能直接告诉你在某个 radix 下字符对应哪个数值，比手动 switch 大小写字母省太多事。

4.3 负数和边界：toBinaryString(-1)为什么全是1

进制的坑里最经典的一道题是：Integer.toBinaryString(-1)输出什么？答案是32个1：11111111111111111111111111111111。为什么不是 "-1"？因为 Integer.toBinaryString 内部返回的是 int 在内存中的补码表示，负数直接以二进制的补码形式输出，不会加负号。

这是一道非常好的面试题，因为它把补码、位宽和进制三种知识串起来了。同理，Long.toBinaryString(-1L)会输出64个1。理解这个逻辑对于调试位运算特别有帮助，比如你知道Integer.toBinaryString(-1)全是1，就能理解x & -1其实等价于x，而x & -2是清掉最低位。

解析负数时，parseInt 支持带负号的字符串，比如Integer.parseInt("-ff", 16)能正常得到 -255。但是如果你想解析一个已经是用补码形式表示的字符串，比如 "FFFFFFFF"，就不能直接用它，因为按16进制解析它得到的是 4294967295，超出了 int 范围。这种场景你得自己把字符串理解成无符号数再转成 int，或者直接用 Long 来承接。

5. 类型转换与溢出，隐形坑比想象中多

5.1 隐式提升和显式窄化

有了类型范围和进制概念，接下来是实战里天天碰到的类型转换问题。Java 的自动类型转换遵循"小范围到大范围"的规则：byte 可以自动转 short，short 可以自动转 int，int 可以自动转 long，float 可以自动转 double。但反方向就必须显式强转，比如把 double 转 int，把 long 转 int，这时候会发生窄化，超出目标范围的数据直接截断，多余的高位被丢掉。

最典型的一个错误是这样：

long big = 300; byte small = (byte) big; System.out.println(small); // 输出 44

300 在二进制里是 100101100，转成 byte 只保留低8位，也就是 00101100，正好是44。很多初学者以为强转是"四舍五入"，其实强转就是截断二进制位，没有任何舍入逻辑。往小了转是直接砍高位，往浮点转的精度损失则是另一套 IEEE 754 舍入规则。

还有一个小知识点很多人搞混：表达式里的自动提升。byte a = 10; byte b = 20; byte c = a + b;这行代码编译不过，因为 byte 和 byte 相加时会先提升为 int，得到 int 结果，必须强转才能赋回给 byte。同理，int 和 long 相加结果是 long，int 和 float 相加结果是 float。这个提升规则是从"防止运算过程中溢出"的角度设计的，但因为类型被放大，很多人没意识到。

5.2 溢出场景：MAX_VALUE + 1 和 Math.xxxExact

整数溢出可以说是 Java 里最经典的隐形 Bug。看这段代码：

int max = Integer.MAX_VALUE; System.out.println(max + 1); // 输出 -2147483648

int 最大值加1居然变成负数，这就是补码溢出的回绕。二进制里 01111111111111111111111111111111 加1，进位把符号位冲成1，直接变成 10000000000000000000000000000000，也就是 Integer.MIN_VALUE。整个数绕回原点，像汽车里程表一样，跑满一圈清零。

我在真实项目里踩过最狠的一次是在写分页逻辑时，用 int 累加偏移量，结果数据量一大，偏移量直接溢出成负数，导致查询条件变成OFFSET -xxx，数据库直接报错。从那以后，凡是可能长期增加的计数，我第一时间想到的就是 long。

如果你希望溢出时直接抛异常而不是静默回绕，Java 8 以后有了 Math.addExact、Math.subtractExact、Math.multiplyExact 这一组精确运算方法，溢出会抛 ArithmeticException。如果你在写记账、计数器、序列号生成这类不允许回绕的代码，优先用它们。

5.3 实战中的定义规范：金额、开关、ID分别用什么

经验积累到最后其实就是一套自己的选择标准。金额永远不要用 float 和 double，原因前面已经说过，0.1 加 0.2 都不是 0.3，何况是动辄好几位的账目。我自己的习惯是：金额用 long 存最小单位（分），如果牵扯到汇率、折扣等多位小数，直接上 BigDecimal。

状态开关用 boolean 不用 int。别学 C 语言那套用 0 和 1 表示开关，Java 的 boolean 更明确也更安全，不会出现"明明只有 0/1 两种状态，结果线上出现了 2"这种尴尬。ID、时间戳、累加计数用 long，因为 int 的范围在并发频繁的系统里真的不够看，尤其是订单号、用户ID，早晚会撞到天花板。端口号、状态码、年龄这种取值范围明确不会太大的，int 甚至 short 都行。

网络传输和序列化时也要关注类型宽度。同一个 int 字段在二进制协议里固定占4字节，如果你只是传一个 0-100 的值，用 byte 或 short 能把报文体积压下一大截。这种抠字节的行为不是性能偏执，在高吞吐、低带宽的场景下非常实际。

6. 一些琐碎但有用的检查项

聊到最后，我想把平时写代码时会自动过的检查清单分享出来。不保证覆盖所有场景，但确实能帮你避开大部分基础类型相关的坑。

第一，写完表达式先问自己一句：这个结果是什么类型？两个 byte 相加减会得到 int，两个 int 相除会得到 int 而不是小数。很多人写int a = 5; double b = a / 2;以为 b 是 2.5，其实输出 2.0，因为整数除法直接丢掉小数部分。想保留小数，至少要让一个操作数变成浮点，比如a / 2.0。

第二，比较数值时注意类型是否一致。int 和 long 比较时 int 会自动提升成 long，没问题，但 float 和 int 比较就可能出现"看起来相等其实不相等"的情况，因为 float 精度不够。判断两个浮点是否相等，永远不要用==，要用误差范围或者转成 BigDecimal 比较。

第三，打印日志时留意进制。十六进制数据打印出来全是字母和数字，最好统一转成你熟悉的进制再输出。我在调试二进制协议时，习惯把所有字节用String.format("%02x", b & 0xff)拼成 hex 字符串，这样一眼就能看出报文结构。

第四，所有从外部进来的字符串，做进制解析之前先过一遍校验。不要以为Integer.parseInt能处理所有情况，它连前后空格都容忍不了，一定先 trim。如果字符串长度不可控，提前判断一下长度是否超过当前类型的最大位数，免得解析直接溢出或抛异常。

第五点也是我个人最有体会的一点：多看 《Java 语言规范》里关于基本类型的章节，不要停留在面试题层面。规范里没有废话，字面量、自动提升、窄化转换、浮点语义、NaN 和 Infinity 的处理，全都有明确定义。真正把它读透之后，很多"莫名其妙"的线上问题都能在几秒钟内定位到根因。

写代码这些年，我越来越觉得八种基本类型是整个 Java 世界的基石。六种数字类型的范围决定你敢不敢用它扛数据，radix 决定你处理字符串和进制转换时顺不顺手，类型转换和溢出规则决定你能不能在关键时刻保住线上数据。把这些基础抠扎实了，后面学集合、泛型、并发、JVM，都少掉很多拦路虎。如果你也在啃 Java 基础，建议把文里每个代码片段都亲手敲一遍，尤其是手写进制转换那段，敲到你不需要查资料也能默出来为止，那时候你对类型的感知会上一个台阶。