JVM内存模型1.8_JDK 1.8版本JVM内存模型特点

JDK 1.8 JVM内存模型核心变化是永久代被元空间取代：元空间使用本地内存而非堆内存，不参与堆GC，由-XX:MetaspaceSize和-XX:MaxMetaspaceSize控制，字符串常量池仍在堆中，运行时常量池移至元空间。

JDK 1.8 的 JVM 内存模型最核心变化是：永久代（PermGen）被彻底移除，由元空间（Metaspace）替代——这不只是换个名字，而是内存归属、GC 行为和调优逻辑的根本性重构。

为什么 Metaspace 不再报 java.lang.OutOfMemoryError: PermGen space

因为元空间不再使用 JVM 堆内存，而是直接分配在本地内存（native memory）中。只要系统物理内存或虚拟内存没耗尽，就不会因“类太多”而触发该错误。

• -XX:PermSize 和 -XX:MaxPermSize 参数在 JDK 1.8 中

  

  已完全失效，继续配置会被 JVM 忽略（启动时可能报 warning）
• 取而代之的是 -XX:MetaspaceSize（触发首次元空间 GC 的初始阈值）和 -XX:MaxMetaspaceSize（硬上限，默认不限）
• 字符串常量池（"abc" 这类字面量）早在 JDK 1.7 就已从永久代移到堆中，JDK 1.8 仍保留在堆里；但运行时常量池（如类的符号引用、字段/方法签名等）现在属于元空间管理

堆内结构没变，但“方法区”的实现逻辑彻底脱离 JVM 堆

新生代（Eden + S0/S1）、老年代、GC 策略这些堆内划分与 JDK 1.7 一致，但“方法区”这个逻辑概念，现在由元空间承载，且它不参与任何堆 GC 周期。

• 类加载器卸载类时，元空间会释放对应元数据，但不会像永久代那样随 Full GC 被清理——它有自己的独立 GC 触发机制（基于 MetaspaceSize 水位）
• 多个应用共享同一 JVM（如 Tomcat 多 WebApp）时，元空间可复用相同类的元数据（如都用 fastjson），减少重复加载开销；而永久代每个 ClassLoader 都要单独占一份
• 若未设置 -XX:MaxMetaspaceSize，元空间持续增长最终会耗尽本地内存，导致进程被 OS OOM-killer 杀掉（错误日志里看不到 Java OOM，只有 Killed process）

程序计数器、栈、堆仍是线程私有/共享的老样子，但要注意“栈溢出”场景没变

虚拟机栈、本地方法栈、程序计数器这些线程私有区域，在 JDK 1.8 中行为完全不变，StackOverflowError 和 OutOfMemoryError 的触发条件也一样。

• 递归过深、局部变量表过大（比如定义了超大数组作为局部变量）、线程数过多（每个线程默认 1MB 栈空间）仍会导致栈相关异常
• 程序计数器仍是唯一不会发生 OutOfMemoryError 的区域，且永远只存当前字节码行号或 null（native 方法时）
• 别误以为“元空间用了本地内存，堆就安全了”——堆内存不足照样抛 java.lang.OutOfMemoryError: Java heap space，该调 -Xms/-Xmx 还得调

真正容易被忽略的是：元空间的 GC 不是“自动友好型”，它只在达到 MetaspaceSize 后才尝试回收无用类，且是否成功取决于类加载器是否被回收。如果应用频繁生成类（如大量使用 CGLIB、Groovy 脚本、热部署），又没正确释放 ClassLoader，元空间会持续上涨直到触达 MaxMetaspaceSize 或本地内存极限——这时候看监控，会发现 GC 日志里 Metadata GC Threshold 反复出现，但元空间使用量却下不去。