004-Java基本数据类型与内存模型：从一次诡异的调试说起
上周排查一个线上问题，服务在某个数值计算环节偶尔出现精度偏差。日志里打印的浮点数明明该是 0.1，实际参与运算时却变成了 0.10000000149011612。团队里新来的同事盯着调试器发呆：“这 float 是不是坏了？” 我笑了笑，想起自己刚入行时也在这坑里摔过。今天我们就从这个问题出发，聊聊 Java 基本数据类型和它们背后的内存故事。
基本类型不是“基本”那么简单
Java 号称一切皆对象，但基本类型却是例外。int、double、boolean 这些家伙直接趴在栈上，活得比对象轻快。但别小看它们，每个类型都有自己的脾气。比如那个 0.1 的问题，根源就在 float 和 double 的二进制表示上——它们用 IEEE 754 标准，有些十进制小数根本没法精确表示，就像 1/3 在十进制里永远写不完。
// 新手常踩的坑floatprice=0.1f;doubletotal=price*10;// 这里结果可能是 0.999999... 而不是 1.0// 金融计算千万别用 float/doubleBigDecimalcorrect=newBigDecimal("0.1");// 用字符串构造，别用 double 构造栈上的舞蹈：局部变量与操作数栈
方法执行时，每个线程都有自己的栈帧。基本类型就在这上面跳舞。看这段字节码背后的故事：
publicintcalculate(){inta=10;// iconst_10 -> istore_1intb=20;// iconst_20 -> istore_2returna+b;// iload_1, iload_2, iadd, ireturn}istore 把常量压入局部变量表，iload 取出来，iadd 在操作数栈上做加法。整个过程对象都没参与，快得飞起。但这里有个细节：局部变量表以 slot 为单位，int 占一个 slot，long 和 double 要占两个。所以下面这种写法其实有点浪费空间：
voidfoo(){longbig=100L;// 占两个 slotintsmall=1;// 占一个 slot// 局部变量表总共用了 3 个 slot}自动装箱的甜蜜陷阱
Java 5 引入的自动装箱很贴心，但性能坑也不少。Integer a = 100 这行代码，背后其实是 Integer.valueOf(100)。这个方法缓存了 -128 到 127 的值，所以：
Integerx=127;Integery=127;System.out.println(x==y);// true，指向缓存里的同一个对象Integerm=128;Integern=128;System.out.println(m==n);// false，new 了两个新对象循环里频繁装箱拆箱，GC 压力就上来了。曾经见过有人用 Integer 做累加，每秒生成几十万个临时对象，系统卡成幻灯片。
内存布局的实战意义
了解基本类型的内存布局，对性能优化和问题排查都有帮助。比如对象对齐填充（padding）问题：
classBadLayout{booleanflag;// 1 byteintcount;// 4 bytes// 这里 JVM 可能会插入 3 字节的 padding 让 count 按 4 字节对齐}classBetterLayout{intcount;// 4 bytesbooleanflag;// 1 byte// 浪费的空间更少}在内存紧张的环境（比如 Android 或嵌入式设备），这种优化能省出不少空间。用 jol 工具可以查看实际内存布局，有时候调整字段顺序，对象大小能减少 1/3。
数组的内存连续性
基本类型数组在内存中是连续的，CPU 的缓存预取机制特别喜欢这种结构。所以遍历 int[] 比遍历 List 快得多，不仅因为少了装箱，还因为缓存命中率高。但要注意数组越界问题——Java 会做边界检查，每次访问都有个小开销。所以循环时把长度提到外面是经典优化：
// 别这样写for(inti=0;i<array.length;i++){...}// 这样更好intlen=array.length;for(inti=0;i<len;i++){...}浮点数的特殊世界
浮点数有自己的一套运算规则。NaN（Not a Number）不等于任何值，包括它自己。正负零在数值上相等，但 1.0/0.0 得到正无穷，1.0/-0.0 得到负无穷。做科学计算时得小心这些边界情况。有个经验：比较浮点数别用 ==，用差值小于某个阈值：
// 危险写法if(a==b){...}// 安全写法staticfinalfloatEPSILON=1e-6f;if(Math.abs(a-b)<EPSILON){...}个人经验谈
干了十几年 Java，基本类型这块我总结了几条实用经验：
第一，明确场景选类型。做计数器用 int，金融计算用 BigDecimal，科学计算用 double，状态标志用 boolean。别因为 Integer 能 null 就滥用，基本类型的默认值（0、false）往往更安全。
第二，警惕隐式转换。byte 和 short 参与运算会自动提升为 int，long 和 float 混搭可能丢精度。写复杂表达式时，心里要有张类型转换图。
第三，数组优于集合。对性能敏感的场景，能用 int[] 就别用 ArrayList。内存连续性和避免装箱带来的收益，在高频调用中非常明显。
第四，关注内存布局。写 DTO 或缓存对象时，把字段按类型大小排列（8 字节的放前面，4 字节的次之，最后放 boolean 和 byte），能减少 padding 浪费。这在海量对象场景下，内存节省相当可观。
最后回到开头的那个问题——我们后来用 BigDecimal 重写了计算模块，精度问题解决了，但性能下降了 15%。架构没有银弹，每个选择都是权衡。理解数据在内存中的真实面貌，才能做出合适的取舍。下次看到奇怪的数值时，先别怀疑硬件，静下心看看你的数据类型选对了吗。
