java基本类型与包装类转换本质是栈堆间值搬运，开销源于装箱/拆箱：-128~127整数复用缓存，超范围则新建对象增gc压力；集合操作强制装箱拆箱，易致性能瓶颈；应优先用原始类型集合库、数组或optionalint，并统一比较方式。
Java 中基本类型（如 int、boolean）和对应的包装类（如 Integer、Boolean）之间的转换，本质是值在栈与堆之间的搬运和对象生命周期管理，开销主要来自装箱（boxing）和拆箱（unboxing）操作。
装箱和拆箱会触发对象创建与垃圾回收
每次将基本类型转为包装类（例如 Integer i = 100;），JVM 会调用 Integer.valueOf()。对 -128 到 127 范围内的整数，该方法返回缓存对象，无新对象产生；超出范围则每次新建 Integer 实例，占用堆内存，后续需 GC 回收。
- 频繁装箱（如循环中
list.add(i)，其中i是int）→ 大量短命对象 → 增加 Young GC 压力 - 拆箱（如
int x = integerObj + 1;）看似轻量，但若integerObj为null，运行时抛NullPointerException，且仍需检查引用有效性
自动转换在集合和泛型中无法避免
Java 集合（如 ArrayList<integer></integer>）只能存对象，因此向其中添加 int 必然触发装箱；遍历时取元素再参与算术运算又触发拆箱。这种隐式转换容易被忽略，但性能敏感场景（如高频数据处理、实时计算）会明显拖慢执行速度。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
比较操作中 == 和 equals 的陷阱也源于类型混合
用 == 比较两个 Integer，结果取决于是否命中缓存；混用基本类型和包装类（如 int i = 100; Integer j = 100; i == j）虽能编译，但 JVM 会先拆箱再比较，看似简洁实则隐藏一次非必要解引用。
Integer a = 128, b = 128; System.out.println(a == b); // falseInteger a = 100, b = 100; System.out.println(a == b); // true（缓存内）- 统一用
equals()或都转为基本类型再比，逻辑更可控
编译器优化有限，关键靠编码习惯规避
javac 会对部分常量表达式做优化（如 Integer i = 1 + 2; 编译后直接调用 valueOf(3)），但无法消除运行时动态值的装箱。JIT 在热点代码中可能内联 valueOf()，但不会消除对象分配本身。
- 避免在循环内做
Integer.valueOf(x)或new Integer(x) - 方法参数和返回值尽量保持类型一致：需要数值计算就用基本类型，需要 null 表达缺失值再谨慎选包装类
- 用
OptionalInt替代Optional<integer></integer>可彻底避免装箱
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
