使用基本类型集合（如fastutil的Long2ObjectOpenHashMap）替代包装类集合可大幅降低内存占用，案例中堆内存从3.13GB降至211MB，降幅94%；因Integer等包装类单个占16字节，而int仅4字节，百万级规模下内存开销剧增，易引发OOM。
直接用 int 替代 Integer、long 替代 Long，配合专为基本类型设计的集合库（如 fastutil、trove 或 koloboke），能在万级并发场景下大幅削减对象头、引用指针和自动装箱开销——真实案例中，一个 HashMap<Long, HashSet<String>> 重构为 Long2ObjectOpenHashMap<int[]> 后，JVM 堆内存从 3.13GB 降至 211MB，降幅达 94%。
识别包装类集合的“隐性内存黑洞”
Java 集合框架（ArrayList、HashMap、HashSet 等）只能存对象，所以 List<Integer> 实际存储的是 Integer 对象，而非 int 值。每个 Integer 对象包含：
- 12 字节对象头（Mark Word + Class Pointer，64 位 JVM 普遍开启指针压缩）
- 4 字节实际 int 值（已封装）
- 内存对齐填充（通常补至 16 字节整数倍）
也就是说，一个 Integer 占用约 16 字节，而原生 int 仅需 4 字节——**单个元素就多占 300% 内存**。当集合规模达百万级，这种开销会指数级放大，尤其在高并发缓存、实时计算、标签匹配等场景中，极易触发 OOM。
选用适配业务特征的基本类型集合库
不推荐手动实现，应优先选用成熟、生产验证过的第三方库。关键选型依据是：是否支持原生基本类型键/值、是否提供紧凑数组结构、是否兼容 JDK 版本及 GC 行为：
-
fastutil：最主流选择，提供
Long2ObjectMap<V>、IntArrayList、IntOpenHashSet等；支持内存友好的开放寻址哈希表，避免链表节点对象；API 与 JDK 集合高度兼容 - Apache Commons Primitives：轻量，但功能较基础（无泛型 map），适合简单场景
- Trove：历史久，但近年更新慢，部分 JDK 17+ 场景存在兼容风险
例如，将原 Map<Long, Set<String>> 中的 Set<String> 替换为 IntSet（若标签可转为 int），再将外层 Map 替换为 Long2ObjectMap<int[]>，即可消除全部包装对象和字符串引用。
重构时必须同步处理的数据建模与转换
基本类型集合不是“替换 API”那么简单，它倒逼你重新审视数据本质：
-
标签 ID 必须数值化：案例中所有标签均为 int，再用
int[]数组紧凑存储（比IntOpenHashSet更省，因无哈希桶结构） -
规避字符串引用：原
Set<String>中每个字符串除自身内容外，还带对象头、字符数组引用、hash code 缓存等；改为int[]后，完全脱离字符串堆内存 -
注意默认值与空值语义：
int[]无法表示 null，需约定 0 或 -1 为无效标记，并在业务逻辑中统一处理
重构后结构示例：Long2ObjectOpenHashMap<int[]> —— key 是城市 ID（long），value 是该城市下所有商品标签 ID 组成的 int 数组，无任何包装、无字符串、无冗余对象。
落地必须做双写验证与灰度切换
这类底层数据结构变更影响面广，不可直接上线：
- 新老结构并行写入：请求处理时，同时向旧
HashMap<Long, HashSet<String>>和新Long2ObjectOpenHashMap<int[]>写入相同数据 - 定时比对一致性：抽取随机城市 ID，校验两套结构返回的标签集合是否逻辑等价（注意排序、去重、类型转换）
- 监控内存与 GC：重点关注 Old Gen 使用率、Full GC 频次、堆外内存（如 fastutil 的 off-heap 支持）是否异常
- 灰度放量：先切 1% 流量，观察 10 分钟无内存抖动、无业务错误，再逐步扩大至全量
真实生产环境中，该策略让团队在零用户感知前提下完成切换，且后续扩容能力提升 5 倍以上——原来撑满 32G 堆的机器，现在 4G 即可稳定承载同等流量。
