java类型擦除本身不节省内存，反而因强制使用object引用层导致堆内存激增和gc压力上升：值类型需装箱、引用类型占指针宽度、底层object[]无法紧凑存储。
Java 的类型擦除机制本身不节省内存，它只是让泛型“看起来不占额外空间”——但实际运行时，由于擦除后强制使用 Object 引用层，反而显著抬高了堆内存开销和 GC 压力。真正的优化目标不是“擦除本身”，而是避免擦除带来的间接内存膨胀。
擦除不省内存，只是隐藏了类型信息
泛型如 List<string></string> 或 List<integer></integer> 编译后都变成原始类型 List，底层是 Object[]。这看似统一，实则代价明确：
- 所有值类型（
int、long等）必须装箱为对象（Integer、Long），每个对象携带约 12–16 字节对象头 + 对齐填充 - 引用类型虽不装箱，但每个元素仍是一个指针（4 或 8 字节），无法像原生数组那样紧凑存储
-
Object[]数组本身按引用宽度分配，存 100 万个Long，光数组引用就占 ~8 MB，再加 100 万个Long对象，总内存远超原生long[1_000_000]的 8 MB
哪些场景内存压力最明显
擦除的内存代价在数据密集、生命周期长或结构嵌套深的场景中被急剧放大：
- 高频写入的缓冲区：如
Queue<event></event>持续堆积日志事件，对象分散导致 GC 扫描范围扩大、minor GC 频次上升 - 缓存系统中的大 Map：
Map<long user></long>存数十万条，每个User引用 +Long键的双重包装开销叠加 - 批处理中间集合：
List<bigdecimal></bigdecimal>临时计算百万级金额，每个BigDecimal是完整对象，非紧凑数值 - 嵌套泛型：
List<map list>>></map>每一层都引入新对象、新引用跳转，缓存行利用率下降，访问延迟上升
绕过擦除影响的实用路径
不能改变 JVM 的擦除机制，但可通过选型与设计降低其副作用：
- 数值密集场景优先用专用集合：如 Eclipse Collections 的
LongArrayList（底层long[]）、Trove 的TLongArrayList，彻底避开装箱与Object[] - 扁平化嵌套结构：把
List<map v>></map>改为List<record></record>，自定义键值封装类，减少间接引用层数 - 只读大批量数据考虑堆外存储：序列化后用
MappedByteBuffermmap，或用ByteBuffer+ 手动偏移解析，绕过堆对象分配 - 极端性能敏感场景可借助
Unsafe或VarHandle构建类型专用容器，但需严格测试兼容性与安全性
擦除带来的运行时限制也影响内存管理效率
类型信息丢失不仅让反射失效、instanceof 无法判断泛型参数，更深层影响内存行为：
- GC 无法区分“逻辑上同质”的泛型集合（如全是
String的List），只能按通用Object引用扫描，增加标记阶段耗时 - JIT 编译器难以对泛型集合做针对性优化（如内联、向量化），因运行时类型不可知，削弱热点代码性能
- 对象分布稀疏，降低 CPU 缓存行命中率，间接拉高内存带宽压力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
