Integer自动装箱在-128～127外每次put/get都新建对象，导致堆内存激增和Minor GC频繁；应优先用原始类型集合或缓存优化规避。
用 Map<String, Integer> 频繁做 put 和 get，只要涉及 Integer，就大概率在制造临时对象——不是“会不会”，而是“一次操作可能生成几个”。关键不在 Map 本身，而在 Integer 的装箱行为。
自动装箱是对象爆炸的起点
每次你写 map.put("score", 95) 或 int x = map.get("score")，Java 都会隐式调用 Integer.valueOf(95) 和 Integer.intValue()。问题出在 valueOf：
- 值在 -128～127 范围内 → 复用缓存对象，不新增
- 值超出该范围（比如 1000、-2000、时间戳、ID 等）→ 每次都 new 一个新
Integer实例
这意味着：循环插入 1 万个用户年龄（假设平均 45 岁，都在缓存范围内）→ 几乎零额外对象；但插入 1 万个订单 ID（如 1000000001）→ 至少生成 1 万个独立 Integer 对象，全堆上分配。
get 操作也可能悄悄创建对象
map.get(key) 返回的是 Integer，如果你接着用于集合操作或流处理，风险升级：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
-
list.contains(map.get("id"))→get返回Integer，contains接收Object，不触发装箱；但若写成list.contains((int) map.get("id"))，再转回int是安全的 -
stream.map(x -> map.get(x)).collect(...)→ 若 map 中 value 是大数值，每轮都 newInteger，且 Stream 还可能额外包装 - 更隐蔽的是日志：
log.info("id={}", map.get("id"))表面无害，但若日志级别关闭，SLF4J 仍会调用toString()（对Integer是轻量），可忽略；但换成"id=" + map.get("id")就强制触发字符串拼接和中间String创建
替代方案：绕过装箱，直击本质
如果业务确定只存/取 int，别让泛型“替你决定”类型：
- 用
int[]+ 字符串 key 映射表（如预分配数组，key 做 hash 后取模） - 用第三方原始类型集合，例如：
IntObjectHashMap<String>（Trove）、Int2ObjectOpenHashMap<String>（FastUtil）、
或IntArrayList配合外部索引 - 自己封装一层：内部用
HashMap<String, int[]>存单元素数组（复用数组引用），或直接用AtomicInteger（适合计数类场景）
怎么确认你正在创建临时对象
别猜，用工具看：
- 加 JVM 参数：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 Young GC 频率是否随 put/get 密度上升 - 用
jstat -gc <pid>查YGC和YGCT，突增说明短生命周期对象多 - 开启 JFR（Java Flight Recorder）录制 60 秒，过滤 “Allocation in new TLAB”，看
java.lang.Integer是否高频出现在分配热点里
