性能敏感场景下应优先使用基本类型而非包装类，仅在泛型、集合、IO等必要场景才用包装类，并注意空指针、缓存陷阱及边界控制。
性能敏感场景下，基本类型和包装类的取舍核心就一条：能用基本类型绝不用包装类，除非被逼到墙角。
计算密集型代码必须用基本类型
循环累加、数组遍历、数学运算这类操作，每轮拆箱装箱都会带来额外开销。Integer对象比int多占约12字节内存，且每次自动拆箱都要调用intValue()方法，触发方法调用和空值校验。
- 高频循环中避免写
Integer sum = 0;，改用int sum = 0; - 数组运算优先用
int[]而非ArrayList，后者底层是对象引用，缓存局部性差 - JVM对基本类型有大量优化（如栈上分配、标量替换），对包装类几乎不优化
集合与泛型场景绕不开包装类
Java泛型在编译期擦除，运行时只剩Object，而基本类型不是对象，无法作为泛型实参。所以List非法，Map也不合法。
- 所有集合类（
ArrayList、HashMap等）只能存包装类或自定义对象 - 函数式接口如
ToIntFunction或IntConsumer是特例，专为基本类型设计，可避免装箱 - 若需高性能集合，考虑第三方库如Trove、Eclipse Collections提供的
TIntArrayList等原生类型集合
注意缓存陷阱和空指针风险
Integer等包装类有缓存机制（-128~127默认缓存），但超出范围就新建对象；Float、Double无缓存；Boolean只有TRUE/FALSE两个实例。这些细节直接影响==比较结果和内存行为。
- 判等一律用
equals()，别信==——尤其从JSON或数据库反序列化来的Integer可能为null - 方法参数或返回值若声明为
Integer，调用前务必判空，否则拆箱时抛NullPointerException - 用
OptionalInt、OptionalLong替代Integer作返回值，语义更清晰，避免null歧义
特殊场景可混合使用，但要主动控制边界
比如处理配置项时，内部用int运算，仅在IO层转成Integer用于JSON序列化；或用AtomicInteger代替int做并发计数——它本质是包装类，但提供了CAS等原子操作，此时性能让位于线程安全需求。
- 输入/输出边界（JSON、DB、RPC）天然倾向包装类，因需表达“缺失”语义（null）
- 核心算法、批处理、实时计算模块，应严格隔离包装类，入口处拆箱，出口处再包装
- 用IDEA或SonarQube配置检查规则，拦截
new Integer(1)、==比较包装类等高危写法
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
