永久代和元空间是HotSpot对方法区的不同实现：永久代属堆内存、需显式设限、依赖Full GC回收；元空间用本地内存、默认无上限、异步独立GC、职责更清晰。
永久代和元空间都是 HotSpot 虚拟机对 JVM 规范中「方法区」的具体实现，但它们在内存归属、回收机制、配置方式上完全不同。简单说：永久代是堆里的固定小房间，元空间是系统级的弹性云存储。
内存位置与归属差异
永久代属于 JVM 堆内存的一部分，物理上紧邻老年代，受 -Xmx 等堆参数间接影响；元空间完全脱离 JVM 堆，直接使用操作系统的本地内存（Native Memory），由 mmap 或 VirtualAlloc 分配，地址空间归操作系统管理。
- 永久代溢出报错：java.lang.OutOfMemoryError: PermGen space
- 元空间溢出报错：java.lang.OutOfMemoryError: Metaspace
- JDK 8+ 中，永久代参数（如 -XX:PermSize）已彻底失效，强行使用会启动失败或警告
大小限制与配置逻辑
永久代必须显式设定上限，否则采用 JVM 内置默认值（如 JDK 7 64位默认 85MB），超限立即 OOM；元空间默认无硬上限，只受限于系统可用本地内存，但生产环境强烈建议显式设置上限。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 永久代常用参数：-XX:PermSize=64m -XX:MaxPermSize=256m
- 元空间推荐配置：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m
- -XX:MetaspaceSize 不是最大值，而是首次触发元空间 GC 的阈值（默认约 20–24MB）
- 未设 -XX:MaxMetaspaceSize 时，元空间持续扩容，可能耗尽本地内存，容器中易被 OOMKilled
垃圾回收与类卸载机制
永久代的类元数据回收严重依赖 Full GC，且需同时满足三个苛刻条件（ClassLoader 不可达、所有实例已回收、Class 对象无引用），实际几乎不触发；元空间 GC 是异步、独立的，只要 ClassLoader 不可达，关联元数据就会被标记回收。
- 元空间 GC 后会自动调优：通过 -XX:MinMetaspaceFreeRatio 和 -XX:MaxMetaspaceFreeRatio 控制缩容节奏
- 高频类加载场景（Spring AOP、OSGi、热部署）下，元空间响应更快，STW 时间更短
- 动态代理多、自定义类加载器未释放时，元空间增长更隐蔽，需重点监控
内容职责与演进动因
JDK 7 起逐步将字符串常量池、静态变量等移出永久代；JDK 8 中，元空间只存真正的类元数据（Class 结构、方法签名、注解、字节码），其余交由堆管理。这种分离让堆专注业务对象，元空间专注类型定义，职责清晰、GC 目标单一。
- 永久代问题本质：把生命周期极长的类元数据，硬塞进本该管短命对象的堆体系里
- 废弃永久代不是“换个名字”，而是解决结构性矛盾：GC 低效、OOM 频发、调优困难
- 元空间设计也融合了 JRockit（无永久代）思路，推动 HotSpot 与 JRockit 合一趋势
