Java基本类型直接栈分配、无对象开销，选错类型或不当转换会显著增加内存占用、GC压力与CPU开销；int[]比Integer[]省60%堆内存，避免自动装箱、隐式提升和窄化转型可提升响应速度与缓存效率。
Java数据类型转换和内存模型不是语法细节，而是直接影响响应时间、内存占用和CPU使用率的关键因素。用错一个类型或一次不安全的转换，可能让接口平均响应从80ms跳到300ms，甚至触发频繁GC或OutOfMemoryError。
基本类型选择直接决定内存与计算开销
Java基本类型在栈上分配（局部变量）或对象内联（成员变量），没有对象头和引用开销。选错类型会放大内存压力：
-
能用
int就别用Integer：后者是对象，每次自动装箱都创建新实例，增加GC负担；高频场景下，int[]比Integer[]节省约60%堆内存 -
按需截断位宽：用户ID用
long很常见，但如果业务上限是1亿，int完全够用，省下4字节/字段；数组长度永远是int，用long声明会编译报错 -
避免隐式提升陷阱：
byte b = 1; b += 1;合法，但b = b + 1;编译失败——因为b + 1结果是int，不能直接赋给byte；这类错误常导致无意识的类型膨胀
强制转换不只是语法动作，更是运行时检查成本
向下转型（如Object → String）和数值窄化（如long → int）都会引入额外开销：
-
引用类型转型需校验实际类：每次
(Dog) animal都要查对象的vtable，确认是否为Dog或其子类；循环中每万次转型约多耗0.2ms（实测JDK17） -
数值窄化不只丢精度，还可能绕过JIT优化：
double d = ...; int i = (int) d;会让JVM放弃对该表达式的向量化处理，尤其在数学密集型计算中影响明显 -
用
instanceof守门不等于零成本：它本身也是运行时类型检查，高频调用建议结合策略模式或泛型重写，而非反复判断
内存布局决定缓存效率与访问延迟
JVM内存模型中，数据如何排列，直接影响CPU缓存命中率：
立即学习“Java免费学习笔记（深入）”；
-
对象字段按宽度升序排列：JVM默认将
byte/boolean→short/char→int/float→long/double→reference分组填充，减少内存空洞；手动调整声明顺序（如把int id放在String name前）可降低单对象内存占用5%~15% -
数组是连续内存块，但引用数组存的是指针：
String[]每个元素占8字节（64位JVM），真正字符串内容在堆其他位置；换成int[]则全部数据紧挨着，遍历快2~3倍 -
逃逸分析失效时，局部基本类型也可能堆分配：若JVM判定某个
int变量“逃逸”出方法（如被匿名内部类捕获），它会被包装成对象放堆里——这时final修饰和明确作用域能帮JIT做优化
装箱拆箱与泛型擦除是隐形性能杀手
表面简洁的语法糖，背后藏着对象创建和类型擦除的代价：
-
ArrayList<Integer>实际是ArrayList<Object>：每次get()返回Object，再自动拆箱成int，产生冗余类型转换；高吞吐计数场景推荐IntArrayList（如Trove或Eclipse Collections） -
泛型方法调用不生成新字节码，但桥接方法会：编译器为保持多态性插入的
bridge method，在反射或动态代理链路中增加方法查找深度 -
字符串拼接
+在循环内等于持续新建StringBuilder：JDK9+虽有优化，但for循环中仍建议显式复用StringBuilder实例，避免短生命周期对象堆积
