直接用基本类型代替包装类可杜绝高频装箱，如将Integer sum=0改为int sum=0，循环累加和计数必须使用基本类型。
直接用基本类型代替包装类，就能从根上掐断高频装箱的源头。这不是微调，而是语义层面的降级——让数字就是数字，别动不动就变成对象。
循环累加和计数必须用基本类型
把 Integer sum = 0 改成 int sum = 0，把 for (Integer i = 0; i 改成 <code>for (int i = 0; i 。每次装箱都意味着一次 new Integer()，超出 -128~127 缓存范围时更是实打实的对象分配。百万次循环 = 百万个短命对象，Eden 区几毫秒就满。
- 累加、索引、状态标记、临时变量，只要不涉及 null 或泛型约束，一律用 int/long/boolean
- 避免在循环内写
list.add(i)（i 是 int），这会隐式触发Integer.valueOf(i) - 若需保留集合结构，后续再统一转为原始类型容器，而非在热路径上妥协
集合操作优先切换到原始类型替代方案
泛型集合如 List<integer></integer> 是装箱重灾区，尤其在增删查密集场景下。它不是“慢一点”，而是每操作一次都在堆上钉一个新对象。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- Android 环境：用 SparseArray<String> 替代
HashMap<Integer, String>，键直接存 int，零装箱 - Java 后端：引入 Eclipse Collections 的
IntArrayList或IntObjectHashMap，底层用数组存原始值 - 避免
Arrays.asList(1, 2, 3)这类写法——它返回的是List<Integer>，已装箱完毕
日志与字符串拼接必须剥离装箱逻辑
"id=" + id + ", flag=" + flag 看似简单，编译后实际执行的是 StringBuilder.append(Integer.valueOf(id)) 和 Boolean.toString()，后者还会 new char[]。一次点击可能触发数百次装箱。
立即学习“Java免费学习笔记（深入）”；
- SLF4J 场景：改用占位符，
log.info("id={}, flag={}", id, flag)，参数传基本类型不触发装箱 - Android Log：封装一层工具方法，内部用
String.valueOf(id)替代字符串拼接，避开包装类构造 - 高频日志点可预构建 StringBuilder 并复用，避免每次调用都 new 实例
三元运算与方法返回要警惕字面量装箱
Integer status = condition ? 200 : null 是典型陷阱：200 不在缓存范围内，每次执行都 new Integer(200)。哪怕只是赋值给局部变量，对象也已诞生并进入 GC 生命周期。
- 能用基本类型接收就不用包装类：
int status = condition ? 200 : -1 - 接口返回需兼容 null？考虑用 Optional<Integer> 显式表达语义，而非靠包装类“兼职”空值标记
- 检查所有
public Integer getXxx()方法签名，若业务上不可能为 null，直接改为int
