Java HashMap内存优化核心是减少对象开销、避免冗余空间、抑制扩容与哈希冲突，需从初始化（合理设初始容量）、Key设计（用不可变低开销类型）、使用方式（慎调负载因子、避免可变Key）三方面协同控制。
Java HashMap 的内存优化，核心是减少对象开销、避免冗余空间、抑制不必要的扩容和哈希冲突。它不是靠“压缩数据”，而是从初始化、Key 设计、使用方式三个层面控制底层对象数量与分布。
合理设置初始容量，避免频繁扩容
每次扩容都要新建数组、重新哈希所有元素、复制节点，不仅耗 CPU，还临时占用双倍内存（旧表+新表）。空 HashMap 在 64 位 JVM 上至少占 48 字节，每个 Node 又额外占 32 字节——扩容越多次，浪费越明显。
- 按预估元素数反推：初始容量 = ⌈预计元素数 ÷ 0.75⌉，再向上取最近的 2 的幂（如预估 1000 个 → 1334 → 实际用 2048）
- 若无法预估，宁可略大勿小；默认容量 16 很容易在插入第 13 个元素时就触发首次扩容
- Guava 提供了便捷工具：Maps.newHashMapWithExpectedSize(1000)，自动完成上述计算
慎用高负载因子，警惕哈希冲突带来的隐性开销
负载因子决定扩容时机，也直接影响哈希桶的拥挤程度。看似提高负载因子（比如设为 0.9）能省空间，但链表变长后，get/put 的平均时间成本上升，且每个冲突节点都多占一个 Node 对象（32 字节），实际内存未必更少。
- 默认 0.75 是空间与时间的平衡点；对读多写少、响应敏感的场景，可降到 0.5～0.6，换取更低冲突率
- 不要盲目设 0.9——当链表长度普遍 ≥5，就可能已抵消掉节省的数组空间
- 可通过 map.size() / map.capacity() 粗略估算当前填充率，结合 JFR 或 JProfiler 观察实际冲突率
选用不可变、低开销的 Key 类型
Key 不仅影响哈希分布，还直接决定 Node 中 key 引用所指向的对象大小和生命周期。用错 Key，等于给每个键值对“加装累赘”。
立即学习“Java免费学习笔记（深入）”；
- 优先选内置不可变类型：String、Integer、Long、Enum，它们 hashCode 稳定、计算快、无额外字段
- 避免用 List、Map、自定义可变对象作 Key——它们 hashCode 易变，且重写不当时会导致哈希失序、内存泄漏
- 若必须用自定义对象，确保：hashCode 基于 final 字段；equals 与 hashCode 逻辑一致；对象创建后不再修改参与哈希的字段
警惕包装类与嵌套 Map 的内存放大效应
JSONObject（如 Fastjson）本质是 HashMap 包装，每层嵌套都会新增一层 Map 对象头 + Node 数组 + 若干 Node 实例。一个含 10 个字段的 JSON 对象，底层可能生成 10+ 个 Node，外加多个 Map 实例，内存占用远超原始字符串。
- 临时解析场景：用 Jackson 的 JsonNode 或 Gson 的 JsonObject 替代 JSONObject，减少中间包装
- 大批量数据处理：改用流式解析（JsonParser / JsonReader），边读边处理，不全量加载进内存
- 高频构造场景：考虑对象池复用 Map 实例（如 Apache Commons Pool），但需注意线程安全与状态清理
