面经策

为什么 Java 8 移除了永久代（PermGen）并引入了元空间（Metaspace）？ ​

  • 标签：JVM、Java

🏛 业务架构师 ​

这次改动的业务背景是：PermGen 的大小必须手工预设，且装不下"动态性强的业务"。

  • PermGen 是堆内一块固定大小的区域，存放类元数据和字符串常量池。类卸载条件苛刻，一旦业务大量动态生成类——CGLIB 代理、反射框架、Groovy/JS 脚本引擎、热部署——PermGen 就被撑爆，OutOfMemoryError: PermGen space；
  • 早年最典型的事故场景：Web 容器反复热部署应用，旧 ClassLoader 因为一处引用泄漏无法回收，几次重部署就 OOM 重启。对业务的影响是发布不敢用热部署、动态规则引擎不敢上；
  • Metaspace 改用本地内存，默认只受物理内存约束，类元数据随类加载器回收而释放，容量问题从"必须拍脑袋预设"变成"可观测、可动态调整"。

从架构视角看，这是 JVM 把一块"静态配额"变成"弹性资源"的演进，给了业务侧两个自由：动态化技术（动态代理、规则脚本、字节码增强）可以放心用；运维上配合 MaxMetaspaceSize 兜底即可。

顺带纠正一个误区：常量池并入堆、Interned 字符串不再是 PermGen 问题；而 Metaspace 也可能 OOM（泄漏依旧存在，只是天花板高了）。换内存区域解决的是容量刚性，不解决泄漏，监控依然要有。

🏗 系统架构师 ​

我从"定位"和"实践问题"两个层面理解这次改动：

PermGen 的问题：

  • 大小固定（-XX:MaxPermSize），动态生成类多的场景（CGLib 代理、Groovy、JSP 预编译、大量反射）极易 PermGen OOM，调参只能缓解不能根治；
  • 与堆物理隔离，GC 效率低，字符串常量池放这里更是历史包袱（1.7 已移走）；
  • 类元数据本就该随需增长，按固定区域管理是设计错配。

Metaspace 的方案：类元数据移到本地内存（native memory），默认只受物理内存限制，可配 MaxMetaspaceSize 兜底；字符串常量池、静态变量（1.8 仍留 Perm 位置但概念上归堆）早已归堆。本质上 JVM 把"类元数据"从受控的堆划分改为操作系统的内存管理，消除了一整类 OOM。

生产教训：换 Metaspace 不等于不用管——CGLib/反射滥用照样撑爆 native 内存或触发 Full GC（类元数据回收依赖类卸载，动态代理 ClassLoader 泄漏时 Metaspace 仍会涨）。我线上必配 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，并把 Metaspace 使用量纳入监控，元空间的失控是排查"堆没问题但进程 OOM 被杀"的第一嫌疑。

💻 全栈开发专家 ​

PermGen 是 JVM 堆里一块大小固定的区域，放类元数据和字符串常量池，两个致命问题：

  1. 容量难估：动态代理、JSP 热部署、大量注解扫描都会撑爆，OutOfMemoryError: PermGen space 是老系统的经典线上事故。调参全靠玄学（-XX:MaxPermSize）。
  2. GC 效率低：永久代和老年代绑在一起，Full GC 才回收，频率和成本都不合理。

Metaspace 的改进：类元数据改放本地内存（native memory），默认只受物理内存限制，按需扩容；字符串常量池 JDK 7 就已挪到堆里。

text
-XX:MetaspaceSize=256m          # 触发 GC 的阈值，不是初始大小
-XX:MaxMetaspaceSize=512m       # 上限，防止类泄漏吃光物理内存

我处理过的真实案例：定时任务里频繁 Proxy.newProxyInstance/CGLIB 生成代理类且类加载器没释放，Metaspace 持续上涨，用 jstat -gcmetacapacity + Arthas sc -d 查类加载器数量定位。所以即使换成 Metaspace，类泄漏还是类泄漏，上线前我会监控 Metaspace 曲线，配合 -XX:+HeapDumpOnOutOfMemoryError 留证据。