聊到Java，天天打交道的其实不是那些炫酷框架，反而是这八种基本类型。int、long、double、boolean，看起来简单到背下来就完事，但真到写代码时坑一个接一个：Integer用==比较比出个false，金额用double算出一堆小数点，5/2得出2还一脸懵。我写Java有些年头了，坦白讲这些坑我自己都踩过不止一遍。
今天我不打算给你贴一张教科书表格就草草收场，而是想把这八种类型从头到尾捋一遍：它们为什么是这么设计的、每个类型背后有什么限制、实际编码里应该怎么选型，以及我在项目里踩过之后沉淀下来的排查经验。这篇内容适合刚学Java的朋友建立完整认知，也适合写了一两年代码的人回来补漏——我保证后面有几个点你会觉得“原来如此”。
1. 先弄清楚八种基本类型到底是个什么阵容
1.1 一张表看完整阵容
Java的基本类型不多不少恰好八种，按大类分四组：整数类型四种，浮点类型两种，字符类型一种，布尔类型一种。很多新手会问String是不是基本类型，并不是，String是引用类型，底层是字符数组的封装。
先把完整阵容列出来看：
| 类型 | 占用空间 | 默认值 | 表示范围 | 典型场景 |
|---|---|---|---|---|
| byte | 1字节 | 0 | -128 ~ 127 | 文件流、二进制协议、内存敏感场景 |
| short | 2字节 | 0 | -32768 ~ 32767 | 少见，多用于底层协议解析 |
| int | 4字节 | 0 | -2147483648 ~ 2147483647 | 默认整数，循环、数组下标、常规计数 |
| long | 8字节 | 0L | -9223372036854775808 ~ 9223372036854775807 | 时间戳、ID、超大数值 |
| float | 4字节 | 0.0f | 约±3.4E38，有效位数6~7位 | 节省内存的浮点场景 |
| double | 8字节 | 0.0d | 约±1.7E308，有效位数15~16位 | 默认浮点，科学计算、图形计算 |
| char | 2字节 | '\u0000' | 0 ~ 65535 | 单个字符，Unicode代码单元 |
| boolean | 未严格定义 | false | true / false | 布尔判断、状态标记 |
这张表的信息量其实很大，但更值钱的是为什么这么设计。比如char占2字节而不是1字节，因为Java从设计第一天就考虑国际化，用16位存Unicode字符；boolean在规范里没有明确占用大小，因为JVM只是规定boolean数组用byte实现、单独的boolean变量编译后通常占用int空间，这个冷知识后面细说。
1.2 为什么Java要把类型分成“基本”和“引用”两派
理解了“基本”两个字，才算真正理解这八种类型存在的意义。Java把类型分成两大类：基本类型存储在栈上，存的是值本身；引用类型存的是对象的地址，真正的对象在堆上。
打个生活化的比方：基本类型是你钱包里的现金，花多少是多少；引用类型是你手机里的电子钱包余额，卡里记的是数字，钱的实体在别处。正因如此，基本类型没有“空”的概念，你定义了一个int，哪怕不初始化也默认是0；而引用类型可以指向null，表示“没有指向任何对象”。
这个区别直接决定了后面很多经典问题的根源。比如集合框架List 是编译不过的，只能写List ，因为泛型参数必须是引用类型；比如方法传参，基本类型传的是值拷贝，引用类型传的是地址拷贝，所以方法里修改基本类型参数不影响外面的变量，而修改引用类型指向的对象内容会影响外面。
还要补充一个关键点：为什么Java里没有unsigned无符号整数？C语言中unsigned int满天飞，Java把这些砍掉了，设计者的核心考虑是无符号整数会让语言语法变复杂，而且对普通业务开发意义不大。但官方也承认这个需求真实存在，所以Java 8之后提供了Integer.toUnsignedString、Integer.parseUnsignedInt这些静态工具方法，用有符号类型模拟无符号操作。你在写二进制协议解析、读取文件头时，就会理解为什么很多时候要用long去接unsigned int的取值范围。
2. 每种基本类型背后的设计细节
2.1 整数家族：byte、short、int、long
先看byte。它占据8位，范围是-128到127，可能有人疑惑为什么负数下限的绝对值比正数上限大1。这是因为计算机用补码表示负数，补码的设计让0只有一个表示方式（00000000），空出来的10000000就被用来表示-128。补码的好处是加减法可以统一用加法电路实现，CPU不用单独设计减法器，代价就是正数位数少了一个。一个记忆技巧：有符号整数范围的上限是2的n-1次方减1，下限是负的2的n-1次方。
short的存在感在业务开发里很低，正常没人会写short count这种变量，但它在IO流和协议解析中比较常见。FileInputStream读取单字节返回int、DataOutputStream写入short类型数据时，你必须熟悉short的截断和转换规则，否则解析二进制数据会莫名其妙乱码。
int是Java里最常用的整数类型，你写一个裸的1就是int，写个1000也默认int。循环、数组下标、普通计数、状态码，全都用int。int上限21亿，大多数场景完全够用，但一旦涉及ID、时间戳、文件大小等数据量不确定的字段，就尽量不要用int，直接上long。
long占64位，范围是-9223372036854775808到9223372036854775807，约92亿亿。使用long时有个细节容易翻车：字面量必须加大写L后缀，比如100000000000L。小写l不是不行，但和数字1长得太像，阅读代码时极易混淆，社区规范一律推荐大写L。另外long做自增运算同样存在溢出问题，只是范围更大不容易触发。
2.2 浮点家族：float、double
浮点数的底层原理可以理解为科学计数法的二进制版：一个数拆成符号位、指数位、尾数位三部分。
float占32位，分布是符号位1位、指数位8位、尾数位23位，有效十进制数字只有6到7位。double占64位，指数位11位、尾数位52位，有效十进制数字15到16位。很多新手不理解“有效数字”是什么意思，生活化解释就是：float能精确保证前6位数字是可信的，double能保证前15到16位是可信的，超出部分会被截断或舍入。我说的是“可信”，不是说后面的位数完全不能用，而是它已经失真了。
这里必须讲一个几乎每个Java程序员都会遇到的诡异现象：0.1 + 0.2，你用Java算一下，得到的是0.30000000000000004而不是0.3。
原因不在于Java，而在于二进制浮点表示法本身。十进制里你能精确写出1/3吗？写不出来，只能写成0.3333333，因为小数点在十进制里容纳不下无限循环。同理，0.1在二进制里是一个无限循环小数，float和double的尾数位数有限，只能截取一部分，误差自然存在。C语言、Python、JavaScript、Go全都一样，这是计算机浮点数共有的宿命。
所以在Java里默认浮点类型是double，你直接写3.14就是double。想用float必须在数值后面加F或f后缀，比如3.14f。不加F会编译报错，因为把double类型赋值给float属于缩小转换，必须显式强转。这个错误在初学阶段几乎天天见。业务开发中除非你是为了节省内存，否则直接用double就行，但凡是金额、价格这种要求精确的项目，浮点类型一个都不要用，直接上BigDecimal，后面专门讲。
2.3 字符与布尔：char、boolean
char是Java里唯一一个无符号整数类型，占16位，表示范围0到65535，对应的Unicode编码范围是\u0000到\uffff。它可以存中文，因为中文字符在Unicode里的码位基本都在这个范围内。
关键要理解一点：Java设计之初那个年代，Unicode标准还停留在16位时代，所有字符都能用一个大写字母编号装下。后来Unicode扩展了，字符数量超过65536，这时Java官方没有推翻char设计，而是选择继续保留16位char，用两个char拼成一个字符，也就是代理对机制。最典型的例子就是emoji表情，一个emoji在Java里length等于2，用substring取字符时可能取到半个乱码。明白这一点，你就知道处理复杂文本为什么永远优先用String而不是char操作。
boolean只有两个值，true和false，这是唯一一个不关心“大小”的基本类型。但如果你去查JVM规范，会发现其中写的是：boolean单独使用的时候，编译成int的变量在栈上占4字节；boolean数组则采用byte数组布局，每个元素占1字节。不同虚拟机实现也可能有细微差异，所以你在网上看到“boolean占1字节”和“boolean占4字节”两种说法其实都不算错，关键看上下文。
这里顺带提一下数组默认值：int[]的默认元素是0，double[]是0.0，boolean[]是false，char[]是'\u0000'。这些默认值不用手动初始化，JVM会在创建数组时统一处理。
3. 实操中避不开的转换、缓存与精度问题
3.1 隐式转换与显式强转的规则
Java的类型转换分为两种：自动转换和强制转换。自动转换的路线是固定死的，方向只能从范围小的转向范围大的：byte -> short -> int -> long -> float -> double，char -> int -> long -> float -> double。比如int变量和double变量做加法时，int会先自动转成double再运算，结果一定是double，不会丢失整数的精度概念。
但这条规则里藏着一个反直觉的坑：long可以自动转成float。long明明是64位，float只有32位，为什么Java允许这种转换？原因是Java的自动转换看的是“目标类型能否容纳源类型的数量级”，float的指数位足够宽，能表示10的38次方级别的数，long的最大值约9.2乘以10的18次方，从数量级上float装得下，所以编译器放行了。然而float的尾数位只有23位，表示大整数时只能保留前几位有效数字。比如123456789L转成float，你大概率得到1.23456792E8，精度已经丢了。这种丢失编译器不给出任何警告，属于典型的“合法但危险”操作。
强制转换则是反过来，从范围大的类型转向范围小的类型，必须显式写括号强转。强制转换的本质不是四舍五入，而是二进制截断。经典例子是int的300强转byte，300的二进制是1 0010 1100，byte只取最低8位，得到0010 1100，也就是44。所以强转出来的结果可能完全出乎意料，强转前最好先判断值是否在目标类型范围内。
还有一个经常被忽略的小规则：char参与算术运算时会被提升成int。比如'A' + 1的结果是66，'\u0001'加上数字会得到int。很多面试题喜欢考这一点，实际工作中处理字符编码时也绕不开。
3.2 包装类型与自动装箱的缓存坑
每个基本类型都有对应的包装类：Integer、Long、Double、Float、Short、Byte、Character、Boolean。为什么需要包装类？因为集合只能装对象、泛型参数必须是引用类型，而且包装类可以表示null，这是基本类型做不到的。
自动装箱和拆箱是Java 5引入的语法糖，Integer a = 100会被编译器自动翻译成Integer.valueOf(100)，遇到Integer和int做运算时又会自动调用intValue拆箱。语法糖是好东西，但包装类背后藏着一个极其经典的陷阱：缓存机制。
Java的设计者在实现包装类时做了个优化，对Byte、Short、Integer、Long、Character这类包装类，使用valueOf时如果值在某个范围内，会直接返回缓存对象。Integer的缓存范围是-128到127，Character是0到127，Long和Integer一致。这样设计的逻辑很好理解：小范围内的整数在业务代码里被反复使用，没必要每次装箱都新建一个对象，能省下大量内存和GC压力。
看这段代码：
Integer a = 100; Integer b = 100; System.out.println(a == b); // true Integer c = 200; Integer d = 200; System.out.println(c == d); // false100在缓存范围内，a和b指向同一个缓存对象，所以==返回true；200超出范围，valueOf会new两个不同对象，所以==返回false。这里要提醒：==比较的是引用地址，永远不要用它来比较包装类型的数值，一律用equals或Objects.equals。Java的IDE工具其实会对这种写法给出黄色警告，很多人直接忽略了。
顺便说个冷知识：Integer缓存上限默认是127，但可以通过系统参数调整。比如启动参数加上-Djava.lang.Integer.IntegerCache.high=1000，缓存范围就能扩大到1000。这种参数在生产环境不推荐用来“修复”代码问题，但理解它有助于看穿一些诡异的内存占用类故障。
3.3 浮点精度问题怎么破
业务里和金额、费率扯上关系时，float和double都应该直接拉黑。正确的做法是用BigDecimal，但BigDecimal本身也有不少使用上的讲究，踩坑点不比浮点类型少。
第一，构造BigDecimal时一定要用字符串形式。new BigDecimal("0.1")是精确的0.1，而new BigDecimal(0.1)会把double类型0.1背后的完整二进制展开值放进去，得到一个超长小数。你可以在本地跑一下试试，new BigDecimal(0.1)打印出来是一长串0.1000000000000000055511151231257827。所以规范写法是new BigDecimal(String)，或者用BigDecimal.valueOf(0.1)，后者底层也是字符串转换。
第二，除法必须指定精度和舍入模式，否则遇到除不尽的情况会直接抛ArithmeticException。正确写法是a.divide(b, 2, RoundingMode.HALF_UP)，表示结果保留两位小数、四舍五入。舍入模式不只是HALF_UP一种，还有向上取整、向下取整、银行家舍入等，金融项目中舍入模式的选择本身就是一个需求点，不要自己拍脑袋。
第三，比较两个BigDecimal时用compareTo，不要用equals。为什么？因为equals不仅比较数值，还比较精度，0.1和0.10在equals眼里是两个不同对象，但数学上它们完全相等。compareTo只比较数值大小，才是业务需要的语义。
非金额场景下如果只是粗略判断两个浮点数是否接近，比如计算几何坐标、图形渲染，可以用Math.abs(a - b) < 1e-9这种方式，给一个可接受的误差范围。这个误差阈值就叫epsilon，很多数值计算库都有类似概念。
4. 常见问题排查与面试高频坑
4.1 经典坑位实录
第一个坑：整数除法取整。int a = 5; int b = 2; 算出来的结果不是2.5而是2。原因很直白：两个整数做除法，结果还是整数，小数部分直接舍掉。解决方案是在除法发生前把其中一个数变成浮点类型：5.0 / 2、5 / 2.0、或者用(double) 5 / 2。只要有一个数是double，整个表达式就会提升为浮点运算。这个坑看起来幼稚，但实际代码里出现在统计报表、平均值计算的场景时，定位起来还真要花点时间。
第二个坑：int溢出后变成负数。Integer.MAX_VALUE是2147483647，再加1会变成-2147483648，也就是Integer.MIN_VALUE。很多性能计数器、下载流量统计、游戏分值累加就是这样突然变成负数的。Java 8引入了Math.addExact、Math.subtractExact这组方法，发生溢出时不是静默出错，而是直接抛ArithmeticException，可以在关键计算场景使用。
第三个坑：死循环。经典面试题是for (int i = 0; i <= Integer.MAX_VALUE; i++)，这个循环永远不会退出。因为i到达最大值后，下一次i++会溢出变成负数，但负数依旧不大于最大值，条件始终为真，于是i从负数一路增长到零，再增长到最大值，循环往复。正确写法是i < Integer.MAX_VALUE，或者干脆把计数器声明为long。这类问题一旦出现在生产环境，表现就是某个定时任务卡死不执行，排查时看日志发现线程还活着，但循环内代码完全没输出。
第四个坑：包装类型拆箱导致空指针。Integer count = null；然后写if (count > 0)，编译器会自动把count拆成int去比较，拆箱那一刻就会抛NullPointerException。特别隐蔽的是三元表达式场景，比如int result = flag ? 1 : null，这个写法看着没问题，但null在参与窄化转换时同样触发拆箱，运行期间直接NPE。建议在项目中做到包装类型和基本类型不混用，尤其是接口返回、数据库映射、JSON反序列化时，明确每个字段是允许为空还是不允许为空。
第五个坑：类型选择不当导致数据库映射异常。比如数据库字段是bigint，值已经超过21亿，用int去接，读出来的数据会溢出成负数。这种问题在规模增长后爆发，并且表现完全没有规律。凡是ID、订单号、时间戳、文件大小，一律long，不要心存侥幸。
4.2 问题速查表
| 现象 | 根因 | 解决方案 |
|---|---|---|
| 5/2得到2 | 整数除法结果截断 | 分子或分母转成double |
| 金额计算出现0.30000000000000004 | 二进制浮点精度有限 | 改用BigDecimal |
| Integer的==比较结果时true时false | 缓存机制只覆盖-128~127 | 用equals或Objects.equals |
| int计数溢出成负数 | 超出2147483647 | 用long，或Math.addExact |
| int 300强转byte得到44 | 强转是二进制截断 | 强转前先判断范围 |
| 包装类型参与运算抛NPE | 自动拆箱遇到null | 避免基本类型和包装类型混用 |
| switch里long不能直接用 | switch支持类型有限 | 改成int或String |
| 文件大小用int存储变成负值 | int范围不够 | 统一用long |
| new BigDecimal(0.1)打印一长串 | 直接将double二进制展开 | 使用字符串构造或valueOf |
| boolean数组每个元素占用大小不确定 | JVM实现差异 | 内存优化时按byte数组思路设计 |
这张表是浓缩的排查手册，遇到同类问题可以直接对号入座。
5. 使用场景选型建议与个人心得
5.1 什么时候用什么类型
这几年的经验告诉我，基本类型选型最重要的不是背范围表，而是养成“按数量级和可变性判断”的思维习惯。
普通算法题、业务逻辑里计数、循环、数组下标、状态码，用int。int是JVM和CPU最友好的类型之一，局部变量的栈上开销和计算效率都很均衡。内存特别敏感的批量数组场景，比如一个百万级元素的开关数组，用boolean[]或byte[]能省不少内存。这里要理解boolean数组在HotSpot虚拟机里按byte处理，每个元素占1字节，比单独用Integer对象省得多。
ID、时间戳、文件大小、自增序列、分布式全局ID这类“不知道未来会不会超过21亿”的字段，直接用long。不要有“现在数据量小用int足够”的赌徒心理，我见过太多系统因为前期图省事用int存ID，后来数据量涨上去才被动改造，代价非常大。
金额相关一律BigDecimal。float和double连碰都别碰。有人觉得数字不大用double没问题，但精度问题不是“数字大才出现”，0.1加0.2就出现了。金额场景没有“差不多”这个概念。
文本处理优先String而不是char。char能表示的只是一个Unicode代码单元，而String处理的是完整字符序列，遇到中文和emoji时String不会让你掉坑里，char的操作容易截出半个字符。
尽量用基本类型作为方法参数和局部变量，避免无意义的包装和拆箱。集合泛型、数据库实体字段、需要表达“可能为空”语义时，才使用包装类型。
5.2 我在实际项目中养成的几个习惯
最后分享几个我踩坑之后定下来的规矩，算不上多高深，但都实打实帮我省过时间。
第一，凡是long字面量，一律大写L后缀，小写l禁止出现。这个规矩看起来小，但代码审查时真的有人把小写l看成数字1，改错过配置。
第二，float字面量一律加F，不加F的3.14是double类型，赋值给float变量就是编译错误。每次写float常量我都顺手补上，宁可多打一个字母也不要让编译器教做人。
第三，包装类型比较永远用equals，哪怕知道值在-128到127之间，也不赌缓存。万一以后需求变了或者代码被复制到另一个JVM参数不同区域，就是个隐藏雷。
第四，写工具方法时如果有人问“参数用int还是long”，我的默认回答是“如果这个值可能被用来做ID、索引、计数，给long”。这会让调用方不自觉地思考值的边界，减少未来溢出风险。
第五，设计实体对象时基本类型和包装类型不要混着来。比如一个用户对象，注册状态用int，手机号用一个包装类，既有基本类型又有引用类型，序列化和判空逻辑都会变得特别别扭。统一风格，宁可多用ArrayList、Optional这些工具类，也要让字段语义清晰。
这八种类型看着基础，里面的门道一点都不少。我见过不少大规模线上事故，追根溯源都是整数溢出、类型强转、精度丢失这几个老面孔。希望这篇分享能帮你把基础重新打得扎实一点，遇到相关问题的时候，脑海里能自动弹出对应的排查思路。
