说个前阵子上线的事。某同事在写交易对账功能时，把一个金额字段定义成了float，结果线上对账差了 0.01 元，大家查了一整天才发现是基本类型用错了。这类问题在项目里太常见了，根子往往不是算法多复杂，而是对 Java 八种基本类型理解不到位。今天我就用一份项目实战总结的口吻，把这八个类型掰开揉碎讲清楚，适合刚学 Java 的新人，也适合干活多年但没系统梳理过基础的老兵。
这篇文章里你会看到：为什么偏偏是这八个、取值范围怎么记、字面量怎么写不会翻车、类型转换什么时候安全什么时候爆雷、包装类和自动装箱藏着哪些坑，以及我实测中遇到的一批经典故障和排查套路。全文没有绕弯子的理论，全是能直接用在工作里的东西。
1. 八种基本类型的整体认知：为什么是这八个
很多初学者一上来就背：“byte、short、int、long、float、double、char、boolean”，背完就完事了。但如果你问一句“为什么是这八个？为什么多一个少一个都不行？”多数人就答不上来了。
按职责划分，这八个类型其实分四族。
| 分类 | 类型 | 位宽 | 典型用途 |
|---|---|---|---|
| 整数 | byte | 8位 | 文件字节流、网络报文、小数组压缩 |
| 整数 | short | 16位 | 控件ID、小范围数值 |
| 整数 | int | 32位 | 绝大多数整数场景 |
| 整数 | long | 64位 | 时间戳、文件大小、大数运算 |
| 浮点 | float | 32位 | 图形计算、非关键精度数值 |
| 浮点 | double | 64位 | 默认浮点类型、科学计算 |
| 字符 | char | 16位 | 单个Unicode字符 |
| 布尔 | boolean | JVM未明确规定 | 条件判断、开关标记 |
四族里的前三个都跟“数”有关，说明 Java 在设计时把数值类型看得特别重。为什么整数要分四档而不统一用一个 int？核心原因是内存与性能的权衡。你在一个数组里面存 10 万个 byte 和存 10 万个 int，前者占 100KB，后者占 400KB，差距立刻就出来了。在嵌入式场景、网络协议解析、图像处理这种对内存敏感的地方，小类型能救命。
浮点分两档也很讲究。float 是单精度，double 是双精度，double 能表示的精度大约翻了一倍。计算中如果你不主动声明，Java 默认所有小数都是 double。这背后有一个很现实的问题：浮点本身就是不精确的，double 虽然精度更高，但也不是精确值。你在账务系统里用任何一种浮点，都是在给自己埋雷，这一点后面专门讲。
char 和 boolean 比较特殊。char 在 Java 里是 16 位，跟 C 语言的 8 位 char 完全不是一回事，它存的是一个 Unicode 码元。boolean 更特殊，JVM 规范没有规定它在内存里占多少字节，实际要看虚拟机实现，很多实现里 boolean 数组一个元素占 1 字节，而单独的 boolean 变量可能被当成 int 来处理。这也是面试里常拿来区分“背了八股”和“真搞过 JVM”的问题之一。
1.1 整数族的四个档位
byte 是 8 位有符号整数，范围从 -128 到 127。很多人会疑惑，8 位二进制不是能表示 256 个值吗？因为 Java 的整数类型是有符号的，最高位是符号位，所以正数最大只能到 127。这样设计是出于一致性的考虑，避免出现无符号类型导致运算符行为不一致。
short 是 16 位，范围 -32768 到 32767。它在日常业务代码里用得不多，但某些算法为了节省内存会用它。int 是默认整数类型，绝大多数循环、计数、状态码都应该是 int。long 是 64 位，范围大到 -9223372036854775808 到 9223372036854775807，适合存毫秒时间戳、文件字节数这类大数值。
选类型时我的建议很简单：拿不准就选 int，涉及时间戳或可能超过 21 亿的数值就选 long。业务系统里绝大多数 int 就够用，刻意去用 short 和 byte 反而容易在类型转换时踩坑。
1.2 浮点族的两档精度
float 是 32 位单精度浮点，能表示大约 7 位有效十进制数字。double 是 64 位双精度浮点，能表示大约 15 到 16 位有效十进制数字。注意我强调的是“有效数字位数”，而不是取值范围。float 的取值范围其实很大，能到 10 的 38 次方量级，但这不代表它精确。
举个例子，你写float f = 0.1f;，打印出来看到的是 0.1，但内存里存的是最接近 0.1 的二进制浮点数，跟数学上的 0.1 并不完全相等。这就是为什么禁止用浮点做金额计算。我见过很多新人问：“我用 double 存 0.1 不就行了吗？”不行，double 存的 0.1 同样不是精确值，只是误差更小而已。
1.3 两个特别存在：char 与 boolean
char 在 Java 中是 16 位无符号类型，范围从 0 到 65535。它存的是 Unicode 字符集里的码元，不是字节。早期设计时 Unicode 还只有 65536 个字符，所以 16 位够用，后来字符集扩到更大的范围，单个 char 就不够表示了，这才引入了代理对的概念。你在处理 emoji 或一些生僻汉字时，会发现字符串长度和字节数对不上，根源就在这里。
boolean 只有两个值，true 和 false，不能跟整数互相转换，这一点跟 C 语言完全不同。C 语言里 0 是 false、非 0 是 true，Java 里你写if (1 == 1)可以，但写if (1)编译直接报错。这个约束让代码更严谨，但也让很多从 C 转过来的新手一时适应不了。
2. 取值范围和字面量：默认类型是最大的坑
字面量就是你在代码里直接写出的值，比如10、3.14、'a'。Java 对字面量有一套默认类型规则，这个规则看起来简单，实际踩坑率极高。
int a = 10; // 10 默认是 int long b = 10; // 合法，int 隐式转 long long c = 10L; // 推荐写法，明确告诉编译器是 long float d = 3.14f; // 必须有 f 后缀 double e = 3.14; // 3.14 默认就是 double double f = 3.14d; // 等价，d 后缀可写可不写 char g = 'A'; // 单引号 String h = "A"; // 双引号，这是 String 不是 char boolean i = true; // 只有 true 或 false2.1 整数字面量默认 int 导致的编译失败
最经典的一个坑：long num = 3000000000;这段代码编译会报错。为什么？因为 3000000000 这个字面量默认被当成 int，而 int 最大值是 2147483647，直接超范围了。正确写法是long num = 3000000000L;。这跟赋值给 long 没关系，问题出现在字面量解析阶段。
还有类似的写法：int x = 017;在 Java 里代表八进制的 17，也就是十进制的 15。int y = 0x1F;代表十六进制的 31。新版本还支持二进制字面量int z = 0b1010;。用下划线分割数字也是合法语法，比如int million = 1_000_000;，但要注意下划线不能放在开头、末尾或小数点两侧。
2.2 浮点字面量默认 double 的连锁反应
float f = 3.14;编译报错，因为 3.14 默认是 double，把 double 赋给 float 是收窄操作，需要强制转换。很多人会写float f = (float) 3.14;或者float f = 3.14f;。我推荐后者，语义更清晰。
更隐蔽的坑出现在方法重载时。你调用foo(1.0)，如果类里同时有foo(float)和foo(double)两个方法，编译器会选foo(double)，因为 1.0 是 double 字面量。如果只定义了foo(float)而没有foo(double)，那么foo(1.0)直接编译失败，你非得写foo(1.0F)才行。这个细节在排查编译问题时尤其有用。
2.3 char、boolean 的写法和内存误会
char 字面量用单引号，里面可以是一个字符、一个转义序列或者一个 Unicode 转义，比如'\u0041'就是 'A'。这里有个特别隐蔽的坑：char x = 'A';里边的 'A' 本质就是整数 65，所以char x = 65;也是合法的，输出 x 时会显示字符 'A'。很多人不理解为什么字符能赋值整数，其实就是因为 char 底层是一段 16 位二进制。
boolean 的写法最单调，没有歧义，但它有个性能层面的细节：JVM 里的 boolean 变量在很多实现中占用不是 1 个 bit，而是可能跟 int 一样占 4 个字节。如果你要建一个包含几百万个 boolean 的数组，内存开销可能远超你想象。这时候就该考虑用 BitSet 或者用 byte 数组来按位存储，这是我们在做大数据布隆过滤器时常用的技巧。
3. 类型转换实战：什么时候安全，什么时候爆雷
类型转换是八种基本类型里最容易出事的环节。我把规则总结成一句话：小类型隐式转大类型安全，大类型强制转小类型会截断。
3.1 隐式提升规则
如果两个类型参与运算，Java 会自动把较小类型提升为较大类型。byte 和 short 在表达式求值时会被先提升为 int，int 加 long 结果就是 long，float 加 double 结果就是 double。这背后的原因是 Java 采取了“统一提升到表达式中最宽类型”的策略，避免每一步都做窄化。
一个典型的坑：
byte a = 100; byte b = 100; byte c = a + b; // 编译错误！a 和 b 都是 byte，但做加法时都被提升为 int，相加结果是 int，把 int 赋给 byte 就是窄化，必须强制转换。正确的写法是byte c = (byte) (a + b);。这里还要注意，100 加 100 等于 200，即使 byte 放不下，编译器也不会在编译时给结果兜底，你只能在运行时面对截断后的 -56。
3.2 强制转换与数据截断
强制转换的语法就是在目标类型加上圆括号，比如int x = (int) longValue;。问题是强制转换并不是做数学上的四舍五入，而是直接截断高位。我用一个最直观的例子说明：
long big = 3000000000L; int small = (int) big; System.out.println(small); // 输出 -1294967296原因很简单：long 的二进制表示有 64 位，int 只保留低 32 位，而这 32 位恰好以 1 开头，于是就成了负数。很多人会把这种结果叫“溢出”，其实说得准确一点，这是二进制表示的截断，不是数值模拟里的溢出。
浮点转整数也有类似问题。(int) 3.99结果是 3，不是 4，因为强转是向零截断，不是四舍五入。你要是写个(int) (score + 0.5)来四舍五入，碰上负数又不对，因为 -3.5 加 0.5 等于 -3.0，转成 int 是 -3，而数学上 -3.5 四舍五入应该是 -4。这种细节做报表和考试系统的人会碰到。
3.3 混合运算的类型提升
混合运算比单变量强转更隐蔽：
int count = 5; long total = 100L; long result = count * total; // int 和 long 相乘，结果是 long这个没问题。但如果写int result = count * (int) total;而 total 超过 int 范围，结果就会爆炸。还有一种常见写法：
double ratio = 5 / 2; System.out.println(ratio); // 输出 2.0，不是 2.55 和 2 都是 int，整数除法直接截断为 2，然后才被赋给 double。要得到 2.5，必须写成5.0 / 2或者5 / 2.0，让至少一个操作数是浮点类型。这个坑小公司里几乎每周都有人踩，尤其是刚接手报表需求的开发。
4. 包装类与自动装箱：对象化的好处和代价
八种基本类型各自都有一个包装类：Byte、Short、Integer、Long、Float、Double、Character、Boolean。为什么需要包装类？因为集合框架不接收基本类型。你写List<Integer>是合法的，写List<int>直接编译报错。泛型、反射、序列化的很多机制都要求对象，所以基本类型必须有面向对象的“壳子”。
4.1 用包装类去表达“空”的语义
基本类型不能为空，它有默认值。int 的默认值是 0，double 的默认值是 0.0，boolean 的默认值是 false。这在业务上会形成误导。比如数据库里有个字段允许为空，查询出来映射成 int，如果没查到值，你拿到的是 0。但业务上 0 可能表示一个真实的值，也可能是“没有记录”，这两者完全是两回事。
用 Integer 就能把这种情况区分开：null 表示没有值，0 表示真正的零。我们在做订单查询接口时，就专门把“价格是否为空”用 Integer 处理，只有这么写，前端才知道到底该显示“待议价”还是“0 元”。
4.2 自动装箱拆箱的隐藏开销与 NPE
JDK 1.5 开始支持自动装箱拆箱，写起来很方便，但代价是隐藏的对象创建和空指针风险。
Integer a = 100; // 自动装箱，本质是 Integer.valueOf(100) int b = a; // 自动拆箱，本质是 a.intValue()自动拆箱在什么地方最容易空指针？就是判断条件里：
Integer score = null; if (score > 80) { // 空指针异常！ ... }因为score > 80会先把 score 自动拆箱成 int，而 null 无法拆箱，直接抛出 NullPointerException。这个异常在 Java 新版本里提示已经非常“友好”了，直接告诉你哪个变量是 null，但老版本里你只能逐行排查。
性能上，循环里反复装箱会创建大量垃圾对象。你写一个千万次的循环往里塞 Integer 对象，GC 负担瞬间飙升。我跑过一个简单测试，用long数组和Long数组做同样次数的累加，后者耗时差不多是前者的十倍，具体数据还会受 JVM 优化影响，但趋势非常明确。所以大量数值计算场景，能用基本类型尽量用基本类型。
4.3 缓存区间与相等比较的经典陷阱
Integer 有一个缓存机制：默认缓存 -128 到 127 之间的 Integer 对象，调用Integer.valueOf()时，这个区间内的值直接返回缓存对象，不新建。外面的值就新建对象。这导致一个著名结果：
Integer x = 127; Integer y = 127; System.out.println(x == y); // true，因为走了缓存 Integer p = 128; Integer q = 128; System.out.println(p == q); // false，因为两个不同对象 System.out.println(p.equals(q)); // true，因为值相等第一次遇到这个现象的人都会觉得玄学。其实背后的逻辑很简单：JVM 把常用的小整数做了对象复用，就像一个公共物品池子。这个缓存上限可以调整，默认是 127，JVM 参数-XX:AutoBoxCacheMax能改，但绝大多数场景不需要动它。
凡是包装类的相等比较，安全做法只有一个：用equals()或者直接用基本类型拆箱结果做==。千万别拿==去比较两个包装对象，除非你能明确对象来源并且知道缓存机制，否则就是一个隐性炸弹。我曾经在代码评审里看到有人用Long id1 == Long id2去比对订单ID，订单ID 刚好都在 128 以上，结果每次都不相等，业务直接崩了。这种问题排查起来极费时间，因为现象时好时坏，看数据范围才恍然大悟。
5. 实战中的常见故障与排查记录
最后这部分我把自己这些年实践里遇到的高频问题整理成排查笔记，每一件都是真实踩过的坑，有些还闹过线上事故。
5.1 整数溢出：时间戳和计数器的噩梦
前阵子一个活动系统里，我们用一个 int 变量去接系统的运行时长计数，结果系统跑了一段时间后，数值从正数跳成了负数，活动状态判断直接翻转。原因就是计数超过 int 最大值 2147483647，没有溢出保护地继续自增，从 2147483647 加 1 变成了 -2147483648。
排查这类问题，一是看变量字段能否换成 long，二是对连续自增或者累加操作要提前预估上限。项目里对计费相关的累加计数，我一律用 long，即使理论上短时间内不会超，也架不住数据积累和未来扩展。另外一个好习惯是：对可能溢出的乘法运算，先把其中一个操作数转成 long，例如long total = (long) price * count;，这样乘法在 long 的宽度下进行，不会做 int 乘法后再转 long。
5.2 金额计算禁止用浮点类型
这是金融领域必须念叨一百遍的规矩。float 和 double 都是二进制浮点，0.1 这个十进制小数在二进制里是个无限循环小数，所以任何用浮点存金额的都注定有误差。
有个经典的演示代码：
System.out.println(0.1 + 0.2); // 输出 0.30000000000000004你看到输出的一瞬间，应该就能明白为什么对账会差 0.01 了。金额计算要用的方案有三种：用BigDecimal并把值以字符串形式传入构造函数，避免直接传 double；或者把金额转成以“分”为单位的 long 做整数运算；再就是用支持十进制计算的数据库类型配合精确转换逻辑。
我个人的经验是：展示层可以用 double 做快速估算，但任何记账、对账、支付逻辑必须走精确计算，而且BigDecimal的构造函数要写new BigDecimal("0.1")，不能写new BigDecimal(0.1)，后者拿到的还是那个不精确的二进制近似值。
5.3 char、String 与编码的三个小坑
char 是单个 Unicode 码元，String 是字符序列。第一个坑是 char 数组和 String 的转换，str.toCharArray()对于普通字符没问题，但包含 emoji 的字符串长度会异常，因为 emoji 用了代理对，两个 char 才表示一个完整 Unicode 符号。
第二个坑是字符串的字节长度跟编码强相关。一个中文字符在 UTF-8 下占 3 个字节，在 GBK 下占 2 个字节。你在做接口签名验证时，如果服务端和客户端用的编码不一致，算出来的MD5 就会对不上，这个现象排查起来经常要浪费半天。
第三个坑是 char 参与数值运算。char c = 'A'; int i = c + 1;结果是 66，没错，A 的 ASCII 码是 65。这个特性做大小写转换时很方便，但如果不小心用 char 去拼接字符串，比如'A' + 1结果可能是 66 这个数字，而不是 "A1"，具体看上下文。用习惯了基本类型的潜在行为，写起来才能少踩坑。
5.4 八种基本类型故障排查速查表
我把最常见的现象和对应原因整理成一个表，项目里排查问题时可以直接对号入座。
| 现象 | 可能原因 | 处理思路 |
|---|---|---|
| 计数变负数 | int 溢出 | 换成 long，或加溢出保护 |
| 金额对账差 0.01 | float/double 精度误差 | 用 BigDecimal 或 long 以分为单位 |
| 5/2 结果是 2.0 | 整数除法截断 | 改成 5.0/2 |
| Integer 比较结果不稳定 | 缓存区间外的 == 比较 | 用 equals 或拆箱后比较 |
| 自动拆箱空指针 | 包装类为 null 参与运算 | 提前判空或设计默认值 |
| 字符串长度比预想大 | 代理对或编码问题 | 用 codePointCount 等方法处理 |
| long 赋值大数编译失败 | 字面量默认 int | 数字后加 L |
| byte 相加编译报错 | 类型提升为 int | 显式强转回 byte |
还有一个我特别想说的小技巧：在排查这类问题时，别急着改代码，先在本地写一个最小复现用例，用javap -c或者 debugger 看编译后的字节码，很多隐蔽问题一眼就能看出来。比如自动装箱到底调用了哪个方法，一查字节码全明白。
最后再分享一个我个人的习惯：凡是核心模型里面涉及的字段，写之前我都会先过一遍类型边界和业务语义，该用 long 的不用 int，该用包装类的不用基本类型，该用 BigDecimal 的绝不用 double。基础八种类型谁都认识，但只有把它放在真实场景里去琢磨取值范围、转换规则和对象化代价，你才算真正掌握。这套思维方式，比单纯背下来八个类型名字重要得多。
