java自动装箱与拆箱是编译器行为，本质为插入valueof()和xxxvalue()调用；装箱复用缓存（-128~127），拆箱遇null抛npe；泛型集合操作存在性能开销，string转换需用专用方法。
Java 自动装箱与拆箱本质是编译器在基本类型和包装类之间自动插入转换逻辑，不是 JVM 运行时特性。它简化了代码，但隐藏了 valueOf() 和 xxxValue() 的调用，稍不注意就可能触发空指针、缓存误判或性能问题。
自动装箱：背后全是 valueOf() 调用
当你写 Integer i = 100;，编译器实际生成的是 Integer i = Integer.valueOf(100);。同理，Boolean b = true; 对应 Boolean.valueOf(true)。
- 所有标准包装类（Byte、Short、Integer、Long、Character、Boolean）的自动装箱都走
valueOf()，而非构造器——这是为了复用缓存对象 - Integer、Byte、Short、Character、Boolean 缓存固定范围：-128 到 127（Character 是 0–127），超出范围每次新建对象
- Long 和 Float 的缓存行为依赖 JDK 版本和启动参数（如
-Djava.lang.Long.IntegerCache.high=200可扩展 Long 缓存上限） - 自定义包装类不会被编译器识别，无法触发自动装箱
自动拆箱：null 是最大雷区
写 int x = integerObj; 看似简单，运行时实际执行 integerObj.intValue()。一旦 integerObj 为 null，立刻抛出 NullPointerException。
- 常见高危场景：从 Map、JSON 解析结果、数据库 ORM 实体中取值后直接赋给基本类型
- 三元表达式陷阱：
Integer a = null; int b = a != null ? a : 0;在部分 JDK 版本中仍会先尝试拆箱 a 导致 NPE（JDK 8u40+ 已修复，但旧环境需警惕） - 集合遍历也危险：
for (Integer num : list) { sum += num; }若 list 含 null 元素，循环第一轮就崩溃
泛型与集合中的隐式转换成本
泛型擦除导致装箱/拆箱只发生在“边界”：向 List<integer></integer> 添加 int 值时必须装箱；从中读取并赋给 int 变量时必须拆箱。
- 频繁操作（如数值计算循环）会带来可观的对象创建开销和 GC 压力
- 性能敏感场景建议优先用基本类型数组（
int[]）或第三方库（如 Eclipse Collections、Trove）替代List<integer></integer> - 使用 Stream 时注意：
list.stream().mapToInt(Integer::intValue).sum()比list.stream().mapToInt(i -> i).sum()更安全（后者仍会触发自动拆箱）
类型转换混淆：String ↔ 数值的正确姿势
自动装箱/拆箱不涉及 String 类型，但开发中常与之混用，容易写出错误链式转换。
- 基本类型 → String：推荐
String.valueOf(i)或"" + i；包装类 → String 直接调用toString()（但注意 null 安全） - String → 基本类型：必须用
Integer.parseInt(s)等静态方法，失败抛NumberFormatException；转包装类用Integer.valueOf(s)，同样抛异常且不接受 null 字符串 - 避免错误写法：
int i = (int) "123";（编译不通过）、Integer i = "123";（类型不兼容）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
