泛型本身不增加内存占用，真正影响内存的是擦除后强制使用的Object引用层：值类型需装箱、引用类型仍占指针宽度、底层Object[]无法紧凑存储，导致堆内存激增和GC压力上升。
泛型本身不直接增加内存占用，真正影响内存的是泛型擦除后留下的 Object 引用层——尤其在大规模数据存储场景下，这会显著抬高堆内存开销和 GC 压力。
泛型擦除强制使用 Object 引用
Java 编译器将 List、List 等全部擦除为原始类型 List，内部元素统一以 Object 类型存储。这意味着：
- 所有值类型（如
int）必须装箱为Integer对象，每个对象额外携带 12–16 字节对象头 + 对齐填充 - 引用类型虽无需装箱，但每个元素仍是一个指向堆中对象的指针（通常 4 或 8 字节），无法像原生数组那样连续紧凑布局
- 集合本身（如
ArrayList）底层仍是Object[]，即使你只存Long，数组每个槽位也占一个引用宽度，而非 8 字节 long 值
对比：泛型集合 vs 原生数组的内存差异
以存 100 万个 long 为例：
-
long[1_000_000]：约 8 MB（纯数据，连续栈/堆分配） -
List（实际是Object[1_000_000]）：约 8 MB 数组引用 + 100 万 ×Long对象（每个约 24 字节）≈ 32 MB+ - 额外成本还包括：对象分散导致 GC 扫描范围扩大、缓存行利用率下降、频繁 minor GC
哪些场景内存压力最突出
以下情况会放大擦除带来的内存负担：
- 高频写入的实时日志缓冲区（如
Queue持续堆积） - 缓存系统中大量
Map或Map实例 - 批处理中临时构建百万级
List进行计算 - 嵌套泛型，如
List，每层都引入额外对象包装和引用跳转
缓解策略：绕过擦除限制的实用方法
不能改变 JVM 的擦除机制，但可通过设计降低影响：
- 对纯数值场景，优先用
IntArrayList、LongArrayList（如 Eclipse Collections 或 Trove 库），它们内部使用int[]、long[]直接存储 - 避免深层嵌套泛型；能扁平化结构就不用
List，改用自定义键类封装 - 大容量只读数据考虑序列化后 mmap 到堆外，或使用
ByteBuffer+ 手动偏移解析 - 必要时用
@SuppressWarnings("unchecked")配合Unsafe或 VarHandle 构建类型专用容器（需严格测试）
