必须改——因PermGen受硬件约束：地址空间解耦失败、缓存局部性差、全局锁瓶颈、NUMA亲和缺失；Metaspace以本地内存分块管理，适配64位架构、TLB、多核与NUMA。
这个问题其实是在问：为什么不是“Java 8 可以改，也可以不改”，而是“必须改”——背后有硬件层面的刚性约束。
物理内存容量与地址空间解耦的需求
64位系统普及后，虚拟地址空间极大（通常达248字节以上），但JVM堆仍被人为限制在几十GB量级。而PermGen却和堆共用同一片连续虚拟内存区域，大小又必须静态预设（如-XX:MaxPermSize=256m）。这种设计在硬件资源日益丰裕的今天，成了人为制造的瓶颈：
- 类元数据（尤其是现代框架动态生成的代理类、Lambda形变类、模块化JPMS的模块描述符）增长快、不可预测，固定上限极易触达
- 堆内存可弹性伸缩（如G1/CMS支持动态扩容），但PermGen卡死在启动时分配的那块连续地址段里，无法按需映射新页
- 本地内存（native memory）由操作系统直接管理，支持按需 mmap 分配离散页，天然适配现代CPU的TLB和页表机制
CPU缓存与内存访问局部性的冲突
PermGen把类名、方法签名、常量池等符号信息和字节码混存在同一块连续堆内存中，导致GC扫描时缓存行利用率低；更关键的是，这些数据生命周期极长（常驻整个应用周期），却和短命对象挤在同一代里，严重干扰分代GC的局部性假设：
- 老年代GC时被迫扫描大量只读元数据，拖慢停顿时间
- CPU L1/L2缓存频繁加载无用的类结构字段，挤占真正活跃对象的缓存空间
- Metaspace将元数据按ClassLoader隔离存储在独立虚拟内存段，配合chunk分配，使同一类加载器下的元数据在物理页上更紧凑，提升TLB命中率
多核并发类加载的锁竞争瓶颈
PermGen采用全局锁保护元数据分配，所有线程加载类时都要争抢同一把锁。随着微服务、容器化部署普及，单JVM内ClassLoader实例数激增（每个Spring Boot Actuator端点、每个热加载模块都可能带新Loader）：
- 类加载高峰期出现明显safepoint延迟，表现为“Application time”飙升但CPU空转
- Metaspace底层使用Per-ClassLoader的ChunkList + CAS分配，彻底消除全局锁，让类加载变成近乎无锁操作
- 这一优化只有依托本地内存的细粒度页管理才可行——堆内存的统一GC管理模型无法支撑这种并发粒度
NUMA架构下内存亲和性的缺失
现代服务器普遍采用NUMA架构，跨节点访问内存延迟可达3倍。PermGen作为堆的一部分，其内存页由JVM统一从任意NUMA节点分配，无法绑定到特定CPU插槽：
- 类加载、反射调用、JIT编译等高频元数据访问路径，频繁触发跨NUMA节点访存
- Metaspace可通过Linux的membind或migratepages工具，将ClassLoader关联的元数据页绑定至对应Socket的本地内存，降低关键路径延迟
- 这种硬件级亲和控制，只有脱离JVM堆管理、交还给OS调度的本地内存才能实现
