高性能场景应优先使用基本类型而非包装类，因其无对象创建、无gc压力、无拆箱开销；必须用包装类时需控制生命周期，并在排序、范围检查等场景显式解包或使用对应基本类型api。
高性能场景下，包装类和基本类型的选型不能只看“写起来方便”，得盯住三件事：内存开销、执行路径是否稳定、JVM能不能真正优化到位。核心原则是——能用基本类型的地方，别用包装类；必须用包装类时，得控制它的生命周期和使用方式。
计算密集型逻辑优先用基本类型
循环累加、数值范围判断、高频数学运算等场景，基本类型直接在栈上操作，无对象创建、无GC压力、无拆箱开销。
- 写
int sum = 0; for (int i = 0; i ，字节码是纯寄存器操作（<code>iadd），毫秒级压测延迟稳定 - 写
Integer sum = 0; for (int i = 0; i ，每次迭代都触发自动装箱（<code>Integer.valueOf()）和拆箱（intValue()），堆内存持续分配，GC频率上升，实测耗时可能高出5–10倍 - 尤其注意
long和Long在大循环中的差距更明显，因为Long对象头更大，缓存行利用率更低
集合与泛型中避免隐式装箱滥用
用 List<integer></integer> 没问题，但高频读写时要警惕“看似简单、实则昂贵”的写法。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 不要在循环里反复调用
list.get(i)做算术，比如sum += list.get(i);—— 每次都拆箱 - 改成先转成基本类型数组或用
IntStream：list.stream().mapToInt(Integer::intValue).sum()，JVM可内联且避免中间对象 - 若集合只读且元素量大，考虑用
gauva的IntArrayList或Eclipse Collections的MutableIntList，绕过泛型擦除带来的装箱成本
比较操作按语义分层处理
不是统一用 equals 或 ==，而是根据数据来源和 null 安全需求动态选择。
- 基本类型之间、或基本类型与非空包装类比较：用
==，字节码最简，JIT 易优化，且不会 NPE - 两个包装类判等（如 DTO 字段校验、Map key 查找）：必须用
equals，避开缓存区间陷阱（Integer a = 200, b = 200; a == b是 false） - 涉及可能为 null 的参数（如 RPC 入参、JSON 反序列化结果）：优先用
Objects.equals(a, b)，它内部短路处理 null，比手写a != null && a.equals(b)更紧凑，压测中长稳性更好
排序与范围判断提前解包
排序本身不慢，慢在比较器里反复拆箱。高频排序（如实时风控评分）要剥离对象层。
- 错误写法：
list.sort((a, b) -> a.compareTo(b))→ 每次 compare 都拆箱两次 - 推荐写法：
list.stream().mapToInt(Integer::intValue).sorted().toArray()，或自定义比较器中显式解包：(a, b) -> Integer.compare(a.intValue(), b.intValue()) - 对时间敏感的 range check（如
if (value > MIN && value ），确保 <code>value是基本类型变量，而非每次从包装类取值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
