jdk 8起元空间取代永久代，因永久代属堆内存、大小固定易oom，而元空间使用本地内存、动态伸缩、gc解耦且更契合方法区本质。
永久代和元空间，都是 HotSpot 虚拟机对 JVM 规范中「方法区」的具体实现，不是规范本身，而是实现方式。区别核心不在名字，而在内存归属、管理逻辑和设计目标——JDK 8 彻底用元空间取代永久代，是为了解决永久代长期存在的硬伤。
内存位置与归属完全不同
永久代属于 JVM 堆内存的逻辑分区，物理上虽与老年代地址连续，但被划为独立区域，受 -Xmx 整体堆限制；元空间则完全脱离 JVM 堆，直接向操作系统申请本地内存（Native Memory），不参与堆内存分配与回收流程。
- 永久代满时抛 java.lang.OutOfMemoryError: PermGen space
- 元空间满时抛 java.lang.OutOfMemoryError: Metaspace
- 永久代参数如 -XX:PermSize 和 -XX:MaxPermSize 在 JDK 8+ 已失效
- 元空间使用 -XX:MetaspaceSize（触发初始GC的阈值）和 -XX:MaxMetaspaceSize（可选上限）控制
大小限制与伸缩机制差异显著
永久代大小在 JVM 启动时就固定，无法动态扩容，必须靠人工预估并配置参数，稍有偏差就容易 OOM；元空间默认无上限（Windows 下 -XX:MaxMetaspaceSize=-1），仅受限于系统可用物理内存，能随类加载需求自动增长。
- 动态代理、CGLib、Spring AOP 等大量生成类的场景下，永久代极易耗尽
- 元空间在类卸载后可及时归还本地内存，配合 ClassLoader 回收更高效
- 未设 MaxMetaspaceSize 时，极端情况可能耗尽系统内存，影响其他进程
垃圾回收机制彻底解耦
永久代的回收依赖 Full GC，与老年代强绑定，停顿时间长、不可控；元空间的类元数据回收由专门的元空间 GC 触发，可独立于堆 GC 运行，且支持更精细的类卸载条件判断。
- 类卸载需同时满足：该类所有实例已不可达 + 加载它的 ClassLoader 已被回收
- 自定义 ClassLoader 若未显式关闭或存在静态引用，会导致元空间持续增长
- JDK 7 已开始将字符串常量池从永久代移至堆中，为 JDK 8 彻底移除铺路
演进本质是架构理念升级
永久代是 HotSpot 早期为统一分代管理而做的“权宜之计”，把方法区也纳入堆内 GC 体系；元空间回归方法区本意——作为元数据存储基础设施，应与堆生命周期解耦、与底层系统资源对齐。这也让 HotSpot 更好地兼容 JRockit 的设计理念（JRockit 本就没有永久代）。
- JDK 6：永久代承载全部方法区数据（类信息、常量池、静态变量等）
- JDK 7：常量池和部分符号引用迁出永久代，为过渡做准备
- JDK 8：永久代彻底移除，元空间成为唯一实现，本地内存成新载体
