集合容器自身引用开销显著：hashmap等持有大量引用（4/8字节），扩容导致冗余空间超50%，concurrenthashmap内存碎片更严重；应使用jol精确测量、预设容量、优选原生数组或专用集合结构。
集合对象本身不存数据，但引用开销不可忽略
在大对象存储场景（比如缓存百万级 User 实例）中，很多人只关注单个对象大小，却忽略 ArrayList、HashMap 这类集合容器自身的堆内存开销。它们不存业务数据，但会持有大量引用——每个引用在 64 位 JVM（开启指针压缩时）占 4 字节，未开启则占 8 字节。
以 HashMap 为例：默认初始容量 16，负载因子 0.75，实际扩容阈值是 12。插入 100 万个 User 对象时，它大概率会扩容到 2^20（约 104 万）桶数组，即分配一个长度为 1 的 <code>Node[] 数组。这个数组本身就要占 2^20 × 4 = 4MB（指针压缩开启），还不算链表/红黑树节点对象开销。
-
ArrayList的elementData数组同样存在“容量 > size”现象，冗余空间可能达 50% 以上 -
ConcurrentHashMap在 Java 8+ 使用分段Node[]+TreeBin，内存碎片更明显，且每个 segment 都有独立锁对象开销 - 使用
Arrays.asList()包装的集合是Arrays$ArrayList，底层直接复用传入数组，无额外引用数组，但不可扩容
用 JOL 精确测量集合基础结构大小
别靠估算，用 org.openjdk.jol:jol-cli 直接看运行时布局。它能暴露对象头、对齐填充、引用字段、数组元数据等真实占用。
例如测量空 HashMap：
java -jar jol-cli.jar internals java.util.HashMap
输出会显示：java.util.HashMap 对象头 12 字节 + 4 个 int/float 字段（共 16 字节）+ 1 个 Node[] 引用（4 字节）+ 对齐填充 → 共 32 字节（64 位 JVM + 指针压缩）。而它的 table 字段指向的数组，是另一块独立内存。
- 测量带数据的实例，必须用
VM.current().addressOf(obj)或ClassLayout.parseInstance(obj).toPrintable()，否则只看到类模板 -
ArrayList的elementData数组长度为 10 时，数组对象本身占 24（头）+ 4（length）+ 10×4（引用）+ 对齐 = 64 字节 - JOL 不模拟 GC 压缩，所以对老年代大集合的“实际驻留大小”仍有偏差，但比
ObjectSizeCalculator更可靠
避免 HashMap 的隐式扩容与哈希冲突放大内存
高频 put 操作触发扩容时，JVM 需要同时持有新旧两个 Node[] 数组，瞬时内存翻倍。更隐蔽的是哈希冲突：若 key 的 hashCode() 实现低效（如恒返回 0），所有元素挤进同一个桶，链表转红黑树后，每个 TreeNode 比 Node 多 3 个引用字段（parent、left、right），单节点从 24 字节涨到 40 字节以上。
- 初始化
HashMap时显式指定容量：new HashMap(expectedSize / 0.75f + 1)，避免多次扩容 - 确认 key 类型重写了
hashCode()和equals()，且分布均匀；用key.hashCode() & (n - 1)模拟桶索引，快速验证是否扎堆 - 对只读场景，用
Map.copyOf()（Java 10+）生成不可变副本，底层可能共享数组或做紧凑压缩 - 考虑用
IdentityHashMap替代（如果语义允许），它用System.identityHashCode()，规避自定义哈希实现缺陷
大集合场景优先选数组或专用结构，而非泛型集合
当明确知道元素类型和访问模式时，ArrayList<user></user> 是最差选择之一：泛型擦除导致 Object[] 存储，每个 User 引用都多一层间接；而 User[] 数组直接持有对象引用，无包装、无接口虚调用、GC Roots 更扁平。
- 用
User[] users = new User[capacity]替代ArrayList<user></user>，节省约 16–24 字节/实例的容器开销 - 需要键值映射？考虑
ObjIntMap<user></user>（来自 Eclipse Collections）或LongObjectHashMap（HPPC），它们用原生数组替代Object[]，避免装箱和引用跳转 - 如果集合生命周期长且写少读多，启用 JVM 参数
-XX:+UseCompressedOops（默认开启）和-XX:CompressedClassSpaceSize=256m，防止指针压缩失效导致引用膨胀
真正吃内存的往往不是那个百万级 User 对象本身，而是你随手 new 出来的第 3 个 HashMap —— 它的桶数组正在后台默默占着 8MB 连续堆空间，而你还在 debug 为什么老年代回收不动。
