防范java自动装箱拆箱风险，核心是识别触发场景并主动控制：优先用valueof()避免new、拆箱前判空、比较用objects.equals()、性能敏感处用原始类型集合。
防范Java中自动装箱与拆箱的隐式转换，核心不是禁用它，而是提前识别风险点、主动控制转换时机、避免依赖编译器“替你决定”。关键在于理解哪些场景会悄悄触发装箱/拆箱，并用更明确、更安全的方式替代。
明确装箱来源，优先用valueOf()而非new或直接赋值
直接写 Integer i = 100 看似简洁，但背后调用的是 Integer.valueOf(100)——这本身没问题，但若误用 new Integer(100) 就绕过缓存、无谓创建对象。更隐蔽的风险是：某些工具类或框架内部可能隐式调用构造器。
- 统一使用
Integer.valueOf(int)、Boolean.valueOf(boolean)等静态工厂方法，它们支持缓存且语义清晰 - 避免
new Integer(…)（已废弃）、new Boolean(…)等构造器调用 - 对自定义类型或第三方库传入的包装类，不要假设其一定来自缓存，尤其在跨模块交互时
拆箱前必判空，尤其在三元表达式和方法返回值中
拆箱本质是调用 xxxValue() 方法，一旦对象为 null，立刻抛 NullPointerException。最易被忽略的不是显式赋值，而是隐式参与运算或条件判断。
- 三元表达式如
int x = flag ? obj.getValue() : 0—— 若obj.getValue()返回null，拆箱发生在取值后、赋值前，NPE无法避免 - 建议改写为
int x = flag ? (obj.getValue() != null ? obj.getValue() : 0) : 0，或用Objects.requireNonNullElse(obj.getValue(), 0) - 方法参数接收包装类时，若需参与算术运算，先做非空校验：
if (param != null) { result = param * 2; }
比较包装类一律用equals()，必要时配合Objects.equals()
== 对包装类比较的是引用地址，仅在缓存范围内（如 -128~127 的 Integer）“碰巧”成立，超出范围即失效，极易引发逻辑错误。
- 永远不用
==比较两个包装类变量的值，哪怕你“确定”它们在缓存区间 - 用
a.equals(b)，但注意a或b为null时仍会 NPE - 推荐
Objects.equals(a, b)—— 它内部处理了null安全，语义更准确，也更符合业务意图
性能敏感场景彻底规避高频隐式装箱
循环内、高频日志、大数据量计算中，反复装箱会生成大量短生命周期对象，加重GC压力，拖慢吞吐量。
- 集合操作优先用原始类型专用库（如 Eclipse Collections 的
IntList、Trove 的TIntArrayList），避免List<integer></integer> - 日志占位符传参时，确认参数类型：用
log.info("count: {}", count)（count是int）不会装箱；但若传Integer，SLF4J 仍会触发装箱 - 算法内部尽量保持原始类型运算，包装类只用于边界交互（如DAO层返回、API响应封装）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
