永久代被元空间取代：永久代属堆内存、受-Xmx限制，JDK 8起元空间改用本地内存，存储类元数据，GC更高效，参数-XX:PermSize失效，-XX:MetaspaceSize生效。
如果您在分析JVM内存结构时发现方法区的实现方式存在差异，例如在Java 7与Java 8环境中观察到类元数据存储位置不同，则很可能是由于永久代与元空间的演进关系所致。以下是理解二者关系的关键路径：
一、存储位置与内存归属
永久代是JDK 7及之前HotSpot虚拟机中对方法区的一种具体实现，它被划归在JVM堆内存的逻辑范围内，物理上虽与老年代连续，但逻辑隔离；而元空间自JDK 8起完全取代永久代，其内存直接从本地内存（Native Memory）中分配，不再受-Xmx等堆参数约束。
1、永久代位于JVM进程所管理的虚拟内存空间内，大小由-XX:PermSize和-XX:MaxPermSize显式限定。
2、元空间不占用JVM堆空间，而是向操作系统申请本地内存，其上限取决于系统可用物理内存及-XX:MaxMetaspaceSize设置（若未设，则仅受限于本地内存总量）。
3、永久代满时抛出java.lang.OutOfMemoryError: PermGen space；元空间满时抛出java.lang.OutOfMemoryError: Metaspace。
二、存储内容的迁移变化
JDK 7起已开始逐步剥离永久代中的部分数据，至JDK 8完成彻底解耦：字符串常量池、静态变量等运行期可变数据移入堆内存，仅保留纯粹的类元信息（如类名、字段描述、方法签名、注解等）交由元空间管理，从而降低方法区污染风险并提升GC效率。
1、在JDK 6及以前，字符串常量池、类静态变量、符号引用全部驻留于永久代。
2、JDK 7中，interned strings被移至堆中，符号引用迁移至本地内存，类静态变量也转入堆。
3、JDK 8中，元空间仅存储类的元数据，运行时常量池和静态变量均保留在堆中，方法区概念仍存在，但实现载体已变为元空间。
三、垃圾回收机制差异
永久代的回收依赖于Full GC，且与老年代绑定，触发条件被动、频率低、停顿时间长；元空间则引入更细粒度的回收策略，支持在类卸载时同步释放对应元数据内存，并可在达到初始阈值（-XX:MetaspaceSize）后主动触发GC，显著减少因元数据累积导致的OOM概率。
1、永久代垃圾回收仅在Full GC期间执行，且无法单独触发，易造成元数据长期滞留。
2、元空间在类加载器被回收、对应类被卸载时，会自动清理关联的元数据块。
3、当元空间使用量超过-XX:MetaspaceSize设定的初始阈值，JVM将触发一次局部GC尝试回收无用类元数据，该过程不涉及堆内存扫描。
四、配置参数与运行时控制
永久代使用固定参数控制初始与最大容量，缺乏弹性；元空间则提供动态扩容能力，并通过新参数组合实现更精准的资源调控，同时兼容无上限运行模式（即不设-XX:MaxMetaspaceSize），由系统内存兜底。
1、永久代配置参数为-XX:PermSize（初始大小）和-XX:MaxPermSize（最大大小），JDK 8后这些参数已被JVM忽略并提示警告。
2、元空间启用-XX:MetaspaceSize（首次触发GC的阈值）和-XX:MaxMetaspaceSize（硬性上限），未设置后者时元空间可无限增长直至本地内存耗尽。
3、可通过jstat -gc
五、版本演进与兼容性边界
永久代是HotSpot对方法区的历史实现方案，不具备跨JVM规范普适性；元空间是JDK 8标准化后的替代方案，标志着方法区实现与JVM堆内存的彻底解耦，也是当前所有主流JDK 8+版本的唯一方法区载体。
1、JDK 7 update 4起，G1收集器已支持对永久代的并发类卸载，但需显式启用-XX:+CMSClassUnloadingEnabled（CMS）或对应G1参数。
2、JDK 8发布后，永久代被完全移除，相关JVM参数失效，旧脚本中若残留-XX:MaxPermSize将被静默忽略。
3、在JDK 9及以后版本中，模块系统（JPMS）进一步强化元空间职责，模块化元数据亦由元空间统一承载，方法区的语义完整性完全由元空间保障。
