第四章 运行时数据区：JVM的内存疆域（下）
1. 本地方法接口与本地方法栈
1.1 什么是本地方法?
简单地讲，一个Native Method就是一个Java调用非Java代码的接口。一个Native Method是这样一个Java方法：该方法的实现由非Java语言实现，比如C。这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中，你可以用extern "C"告知C++编译器去调用一个C的函数。
"A native method is a Java method whose implementation is provided by non-java code."
在定义一个native method时，并不提供实现体（有些像定义一个Java interface），因为其实现体是由非java语言在外面实现的。
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合 C/C++程序。
1.2 动态链接机制
flowchart LR
subgraph 栈帧
A[动态链接] -->|指向| B[运行时常量池]
end
subgraph 方法区
B --> C[类引用]
B --> D[方法引用]
B --> E[字段引用]
end
subgraph 符号引用解析
C --> F[类加载时转为直接引用]
D --> G[方法调用时定位入口]
end
作用：
- 将字节码中的符号引用（如
java/lang/Object）转换为内存地址的直接引用 - 支持多态性（虚方法表查找）
1.3 本地方法示例
举例1：
public class IHaveNatives{
public native void methodNative1( int x ) ;
public native static long methodNative2() ;
private native synchronized float methodNative3( Object o ) ;
native void methodNative4( int[] ary ) throws Exception ;
}
举例2：
System.currentTimeMillis()
举例3： Thread类的start()内部
标识符native可以与所有其它的java标识符连用，但是abstract除外。
1.4 为什么要使用Native Method
Java使用起来非常方便，然而有些层次的任务用Java实现起来不容易，或者我们对程序的效率很在意时，问题就来了。
-
与Java环境外交互： 有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。你可以想想Java需要与一些底层系统，如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节。
-
与操作系统交互： JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的。还有，如果我们要使用一些Java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法。
-
Sun's Java： Sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分是用Java实现的，它也通过一些本地方法与外界交互。例如：类java.lang.Thread 的 setPriority()方法是用Java实现的，但是它实现调用的是该类里的本地方法setPriority0()。这个本地方法是用C实现的，并被植入JVM内部，在Windows 95的平台上，这个本地方法最终将调用Win32 SetPriority() API。这是一个本地方法的具体实现由JVM直接提供，更多的情况是本地方法由外部的动态链接库（external dynamic link library）提供，然后被JVM调用。
1.5 本地方法现状
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等，不多做介绍。
1.6 本地方法栈
-
Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
-
本地方法栈，也是线程私有的。
-
允许被实现成固定或者是可动态扩展的内存大小。（在内存溢出方面是相同的）
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个 StackOverflowError 异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个 OutOfMemoryError 异常。
-
本地方法是使用C语言实现的。
-
它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。
-
当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
- 它甚至可以直接使用本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存。
-
并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法，也可以无需实现本地方法栈。
2. 堆内存详解
2.1 核心概述
- 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
- Java 堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
- 堆内存的大小是可以调节的。
- 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
- 堆，是GC ( Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。
- 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。
2.2 堆栈方法区关系
classDiagram
direction TB
class JavaStack {
+局部变量表
+操作数栈
}
class Heap {
+对象实例
+数组
}
class MethodArea {
+类结构
+运行时常量池
}
JavaStack --> Heap : reference引用
Heap --> MethodArea : 元数据指针
MethodArea --> JavaStack : 方法字节码
2.3 对象都分配在堆上吗
-
《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated ) 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
-
我要说的是："几乎"所有的对象实例都在这里分配内存。——从实际使用角度看的。
2.4 所有的线程都共享堆吗
所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer, TLAB)。
2.5 堆的内部结构
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
JDK7 vs JDK8内存模型对比
flowchart TD
subgraph JDK7
A[堆] --> B[年轻代]
A --> C[老年代]
A --> D[永久代]
B --> E[Eden]
B --> F[Survivor0/1]
end
subgraph JDK8
G[堆] --> H[年轻代]
G --> I[老年代]
G --> J[元空间]
H --> K[Eden]
H --> L[Survivor0/1]
J -.->|本地内存| M[方法区]
end
关键变化：
-
JDK8移除永久代，元空间使用本地内存
-
字符串常量池移至堆中
-
Java 7及之前堆内存逻辑上分为三部分：新生区+老年区+永久区
- Young Generation Space 新生区 Young/New
- 又被划分为Eden区和Survivor区
- Tenure generation space 老年区 Old/Tenure
- Permanent Space 永久区 Perm
- Young Generation Space 新生区 Young/New
-
Java 8及之后堆内存逻辑上分为三部分：新生区+老年区+元空间
- Young Generation Space 新生区 Young/New
- 又被划分为Eden区和Survivor区
- Tenure generation space 老年区 Old/Tenure
- Meta Space 元空间 Meta
- Young Generation Space 新生区 Young/New
下面叫法都是一个意思：
- 新生区<=>新生代<=>年轻代
- 老年区<=>老年区<=>老年代
- 永久区<=>永久代
2.6 年轻代与老年代
-
存储在JVM中的Java对象可以被划分为两类：
- 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致。
-
Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（OldGen）
-
其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）。
-
几乎所有的Java对象都是在Eden区被new出来的。
-
绝大部分的Java对象的销毁都在新生代进行了。
-
IBM 公司的专门研究表明，新生代中 80% 的对象都是"朝生夕死"的。
2.7 堆空间分配比例
%%{init: {'pie': {'textPosition': 0.5}, 'themeVariables': {'pieOuterStrokeWidth': '5px'}}}%%
pie title 堆空间分配
"新生代(1/3)" : 33
"老年代(2/3)" : 67
%%{init: {'pie': {'textPosition': 0.5}, 'themeVariables': {'pieOuterStrokeWidth': '5px'}}}%%
pie title 新生代内部
"Eden(80%)" : 80
"Survivor0(10%)" : 10
"Survivor1(10%)" : 10
2.8 如何设置堆内存大小
-
Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项"-Xmx"和"-Xms"来进行设置。
- "-Xms"用于表示堆区的起始内存，等价于-XX:InitialHeapSize
- "-Xmx"则用于表示堆区的最大内存，等价于-XX:MaxHeapSize
-
一旦堆区中的内存大小超过"-Xmx"所指定的最大内存时，将会抛出OutOfMemoryError:heap异常。
-
通常会将 -Xms 和 -Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
-
heap默认最大值计算方式：如果物理内存少于192M,那么heap最大值为物理内存的一半。如果物理内存大于等于1G，那么heap的最大值为物理内存的1/4。
-
heap默认最小值计算方式：最少不得少于8M，如果物理内存大于等于1G，那么默认值为物理内存的1/64，即1024/64=16M。最小堆内存在jvm启动的时候就会被初始化。
2.9 如何设置新生代与老年代比例
下面这参数开发中一般不会调：
-
配置新生代与老年代在堆结构的占比。
- 默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3
- 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
-
可以使用选项"-Xmn"设置新生代最大内存大小
- 这个参数一般使用默认值就可以了。
2.10 如何设置Eden、幸存者区比例
- 在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1
- 当然开发人员可以通过选项"-XX:SurvivorRatio"调整这个空间比例。比如-XX:SurvivorRatio=8
2.11 垃圾回收流程
Minor GC过程
sequenceDiagram
participant Eden
participant S0
participant S1
participant Old
Eden ->> S0: 存活对象复制到Survivor
loop 年龄+1
S0 ->> S1: 下次GC时交换角色
end
alt 对象年龄>阈值
S1 ->> Old: 晋升老年代
end
关键参数：
-XX:MaxTenuringThreshold=15（默认晋升年龄）
2.12 对象分配金句
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
金句：
- 针对幸存者s0,s1区的总结：复制之后有交换，谁空谁是to.
- 关于垃圾回收：
- 频繁在新生区收集
- 很少在老年区收集
- 几乎不在永久区/元空间收集
2.13 过程剖析
-
new的对象先放伊甸园区。此区有大小限制。
-
当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC/YGC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
-
然后将伊甸园中的剩余对象移动到幸存者0区。
-
如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。
-
如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
-
啥时候能去老年区呢？可以设置次数。默认是15次。
- 可以设置参数：-XX:MaxTenuringThreshold= 设置对象晋升老年代的年龄阈值。
-
在老年区，相对悠闲。当老年区内存不足时，再次触发GC：Major GC，进行老年区的内存清理。
-
若老年区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常 java.lang.OutOfMemoryError: Java heap space
2.14 TLAB线程私有分配
flowchart LR
subgraph Eden
A[TLAB1] -->|Thread1| B[私有分配]
C[TLAB2] -->|Thread2| D[私有分配]
end
E[对象实例化] -->|优先| A
E -->|TLAB不足| F[共享Eden分配]
参数控制：
-XX:+UseTLAB（默认开启）-XX:TLABSize=512K
2.15 栈-堆-方法区引用关系
flowchart TD
A[栈帧] -->|reference| B[堆对象]
B -->|Klass指针| C[方法区类元数据]
C -->|字节码| A
对象内存布局：
┌─────────────────┐
│ Mark Word │ (8B)
├─────────────────┤
│ Klass Pointer │ (4B/8B)
├─────────────────┤
│ 实例数据 │
├─────────────────┤
│ 对齐填充 │
└─────────────────┘
2.16 内存分配原则
针对不同年龄段的对象分配原则如下所示：
- 优先分配到Eden
- 大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态对象年龄判断
- 如果Survivor 区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。
- 空间分配担保 -XX:HandlePromotionFailure
2.17 解释MinorGC、MajorGC、FullGC
JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代；方法区)区域一起回收的，大部分时候回收的都是指新生代。
针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型：
-
一种是部分收集（Partial GC）
-
一种是整堆收集（Full GC）
-
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
- 新生代收集（Minor GC / Young GC）：只是新生代（Eden\S0,S1）的垃圾收集
- 老年代收集（Major GC / Old GC）：只是老年代的垃圾收集。
- 目前，只有CMS GC会有单独收集老年代的行为。
- 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
- 混合收集（Mixed GC)：收集整个新生代以及部分老年代的垃圾收集。
- 目前，只有G1 GC会有这种行为
-
整堆收集（Full GC)：收集整个java堆和方法区的垃圾收集。
MinorGC触发机制
- 年轻代GC(Minor GC)触发机制：
- 当年轻代空间不足时，就会触发Minor GC。这里的年轻代满指的是Eden区满，Survivor满不会引发GC。（每次 Minor GC 会清理年轻代的内存。)
- 因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
- Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。
MajorGC触发机制
老年代GC（Major GC/Full GC）触发机制：
- 指发生在老年代的GC，对象从老年代消失时，我们说"Major GC"或"Full GC"发生了。
- 出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。
- 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
- Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长。
- 如果Major GC 后，内存还不足，就报OOM了。
FullGC触发机制
Full GC触发机制：
触发Full GC 执行的情况有如下五种：
（1）调用System.gc()时，系统建议执行Full GC，但是不必然执行
（2）老年代空间不足
（3）方法区空间不足
（4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存
（5）由Eden区、survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
说明：full gc是开发或调优中尽量要避免的。这样暂时时间会短一些。
2.18 OOM如何解决
1、要解决OOM异常或heap space的异常，一般的手段是首先通过内存映像分析工具（如Eclipse Memory Analyzer）对dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。
2、如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。
3、如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx 与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。
3. 完整内存体系全景图
flowchart TD
subgraph JVM内存
A[线程私有] --> B[程序计数器]
A --> C[虚拟机栈]
A --> D[本地方法栈]
E[线程共享] --> F[堆]
E --> G[方法区]
end
B -->|执行位置| C
C -->|栈帧| F
F -->|对象| G
G -->|类信息| C
3.1 方法区规范说明
flowchart LR
A[方法区] --> B[类元数据]
A --> C[运行时常量池]
A --> D[方法代码]
A --> E[JIT代码缓存]
style A stroke:#f66,stroke-width:2px
关键特性：
- 线程共享
- 可动态扩展
- OOM触发条件：
Metaspace不足（JDK8+）
4. 方法区详解
4.1 运行时数据区全景
flowchart TD
subgraph 线程私有
A[程序计数器] -->|记录指令地址| B[虚拟机栈]
B -->|栈帧| C[局部变量表/操作数栈]
D[本地方法栈] -->|Native方法调用| E[C++库]
end
subgraph 线程共享
F[堆] -->|对象实例| G[年轻代+老年代]
H[方法区] -->|类元数据| I[运行时常量池]
end
style H stroke:#f66,stroke-width:2px
内存异常对比
| 区域 | 错误类型 | 触发条件 |
|---|---|---|
| 堆 | OutOfMemoryError | 对象分配空间不足 |
| 方法区（元空间） | OutOfMemoryError | 类元数据超过MaxMetaspaceSize |
| 虚拟机栈 | StackOverflowError | 栈深度超过-Xss设置 |
4.2 元空间 vs 永久代
JDK7与JDK8内存模型对比
flowchart LR
subgraph JDK7["JDK 7 内存模型"]
direction TB
H7[堆内存]
P7[永久代 PermGen]
S7[字符串常量池在永久代]
H7 --- P7
P7 --- S7
end
subgraph JDK8["JDK 8 内存模型"]
direction TB
H8[堆内存]
M8[元空间 Metaspace<br/>使用本地内存]
S8[字符串常量池在堆中]
H8 --- M8
H8 --- S8
end
JDK7 -->|演进升级| JDK8
style JDK7 fill:#ffebee
style JDK8 fill:#e8f5e8
style P7 fill:#ffcdd2
style M8 fill:#c8e6c9
元空间优势：
- 避免永久代OOM问题
- 自动调整大小（默认无上限）
- 降低GC压力
4.3 永久代参数示例（JDK7）
# 查看PermGen默认值
jinfo -flag PermSize <pid> # 输出示例：-XX:PermSize=21M
jinfo -flag MaxPermSize <pid> # 输出示例：-XX:MaxPermSize=85M
4.4 方法区存储内容
mindmap
root((方法区))
类型信息
类全限定名
父类/接口信息
访问修饰符
运行时常量池
字面量
符号引用
静态变量
类变量
域信息
字段名称/类型
方法信息
方法字节码
JIT编译代码
4.5 运行时常量池结构
flowchart LR
A[.class文件] -->|常量池表| B[运行时常量池]
B --> C[字面量]
B --> D[类/方法/字段符号引用]
B --> E[动态解析后的直接引用]
style B fill:#cff,stroke:#333
4.6 方法区演进历程
三代JDK实现对比
gantt
title 方法区实现演进
dateFormat YYYY
section JDK6
永久代(PermGen) :done, 1996, 2011
section JDK7
字符串常量池迁移至堆 :crit, 2011, 2014
section JDK8
元空间(Metaspace) :active, 2014, 2023
关键变化点：
- JDK6：所有元数据存储在永久代
- JDK7：字符串常量池移至堆
- JDK8：永久代完全被元空间取代
4.7 元空间详细解析
4.7.1 元空间内部结构
flowchart TD
subgraph Metaspace["元空间 (Metaspace)"]
subgraph Klass["Klass Metaspace"]
K1[类元数据]
K2[方法字节码]
K3[常量池缓存]
K4[注解信息]
end
subgraph NonKlass["Non-Klass Metaspace"]
N1[方法计数器]
N2[编译信息]
N3[其他元数据]
end
subgraph CompressedClass["压缩类空间"]
C1[压缩类指针]
C2[类对象引用]
end
end
subgraph Native["本地内存"]
NM[操作系统内存]
end
Metaspace -.->|分配自| Native
style Klass fill:#e3f2fd
style NonKlass fill:#f1f8e9
style CompressedClass fill:#fff3e0
style Native fill:#ffebee
4.7.2 元空间包含的具体内容
| 分类 | 具体内容 | 说明 |
|---|---|---|
| 类型信息 | 类的全限定名、父类、接口列表 | 类加载时创建 |
| 方法信息 | 方法名、参数类型、返回值类型、字节码 | 包含所有方法元数据 |
| 字段信息 | 字段名、类型、修饰符 | 实例变量和类变量描述 |
| 运行时常量池 | 字面量、符号引用、解析后的直接引用 | 动态扩展 |
| 即时编译信息 | JIT编译后的本地代码缓存 | 性能优化相关 |
| 类加载器信息 | 类加载器引用和层次关系 | GC时需要考虑 |
4.7.3 元空间核心参数详解
| 参数 | 作用 | 默认值 | 生产环境推荐 | 设置依据 |
|---|---|---|---|---|
-XX:MetaspaceSize | 初始大小，触发首次GC的阈值 | 约21MB | 256M-512M | 根据应用类数量 |
-XX:MaxMetaspaceSize | 最大限制 | 无限制 | 1G-2G | 防止内存泄漏 |
-XX:CompressedClassSpaceSize | 压缩类空间大小 | 1G | 512M-1G | 64位系统专用 |
-XX:MinMetaspaceFreeRatio | 最小空闲比例 | 40% | 保持默认 | GC触发条件 |
-XX:MaxMetaspaceFreeRatio | 最大空闲比例 | 70% | 保持默认 | 内存回收条件 |
4.7.4 生产环境设置策略
小型应用（类数 < 5000）：
-XX:MetaspaceSize=128m
-XX:MaxMetaspaceSize=512m
中型应用（类数 5000-15000）：
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=1g
大型应用（类数 > 15000）：
-XX:MetaspaceSize=512m
-XX:MaxMetaspaceSize=2g
微服务架构：
# 考虑动态类生成较多
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=1g
-XX:+UnlockDiagnosticVMOptions
-XX:+LogVMOutput
4.7.5 元空间监控指标
flowchart LR
A[元空间监控] --> B[使用量监控]
A --> C[GC频率监控]
A --> D[类加载监控]
B --> B1[当前使用量]
B --> B2[使用率百分比]
B --> B3[增长趋势]
C --> C1[MetaSpace GC次数]
C --> C2[GC停顿时间]
C --> C3[GC触发原因]
D --> D1[已加载类数量]
D --> D2[卸载类数量]
D --> D3[类加载器数量]
style A fill:#e1f5fe
style B fill:#e8f5e8
style C fill:#fff3e0
style D fill:#f3e5f5
4.7.6 元空间大小设置依据
1. 应用类型分析：
# 查看当前加载的类数量
jcmd <pid> VM.classloader_stats
# 查看元空间使用情况
jstat -gc <pid> 1s
2. 框架特性考虑：
- Spring Boot：大量自动配置类，建议
MetaspaceSize=256m - Hibernate/MyBatis：动态代理类较多，建议
MetaspaceSize=512m - 微服务架构：类加载器隔离，建议
MaxMetaspaceSize=1g - 单体应用：类数量相对固定，可适当降低设置
3. 动态类生成场景：
// 常见动态类生成框架
- CGLib代理 (Spring AOP)
- Javassist字节码操作
- ASM字节码生成
- Groovy脚本引擎
- JSP编译
4.7.7 元空间故障排查实战
故障现象：
java.lang.OutOfMemoryError: Metaspace
排查步骤：
flowchart TD
A[元空间OOM] --> B[收集信息]
B --> C[分析原因]
C --> D[制定方案]
D --> E[验证效果]
B --> B1[jstat -gc 查看使用量]
B --> B2[jcmd VM.classloader_stats]
B --> B3[分析GC日志]
B --> B4[Dump堆内存]
C --> C1[类加载器泄漏]
C --> C2[动态类生成过多]
C --> C3[参数设置过小]
C --> C4[内存碎片化]
D --> D1[调整JVM参数]
D --> D2[优化代码逻辑]
D --> D3[升级框架版本]
D --> D4[增加监控告警]
style A fill:#ffebee
style C1 fill:#fff3e0
style C2 fill:#fff3e0
style C3 fill:#fff3e0
style C4 fill:#fff3e0
5. JVM内存体系大总结
5.1 JVM内存设计的核心思想
-
线程隔离与共享平衡：
- 线程私有区（栈/PC）保证执行安全
- 共享区（堆/方法区）减少内存开销
-
分代与分区思想：
- 堆分代提升GC效率
- 元空间分区（Klass/Non-Klass）优化元数据管理
-
动态适应：
- 元空间自动扩展避免永久代固定大小缺陷
5.2 完整内存架构总览
flowchart TD
subgraph JVM["JVM运行时数据区完整架构"]
subgraph Private["线程私有区域"]
PC[程序计数器<br/>字节码指令地址<br/>线程私有<br/>不会OOM]
JVMStack[Java虚拟机栈<br/>局部变量表<br/>操作数栈<br/>动态链接<br/>方法返回地址]
NativeStack[本地方法栈<br/>Native方法调用<br/>C/C++实现]
end
subgraph Shared["线程共享区域"]
subgraph Heap["堆内存"]
Young[新生代<br/>Eden区80%<br/>Survivor0 10%<br/>Survivor1 10%]
Old[老年代<br/>长期存活对象<br/>Major GC目标]
end
subgraph Method["方法区/元空间"]
Meta[类元数据<br/>类型信息<br/>方法信息<br/>域信息]
ConstPool[运行时常量池<br/>字面量<br/>符号引用<br/>动态解析]
end
end
subgraph DirectMem["直接内存"]
Direct[直接内存<br/>NIO缓冲区<br/>Netty应用<br/>不受JVM管理]
end
end
PC -.->|指向| JVMStack
JVMStack -.->|引用| Young
JVMStack -.->|引用| Old
Young -.->|晋升| Old
Meta -.->|类信息| JVMStack
ConstPool -.->|常量| JVMStack
style PC fill:#e1f5fe
style JVMStack fill:#e8f5e8
style NativeStack fill:#fff3e0
style Young fill:#f3e5f5
style Old fill:#ffebee
style Meta fill:#e3f2fd
style ConstPool fill:#f1f8e9
style Direct fill:#fff8e1
5.3 内存区域特性对比总表
| 内存区域 | 线程私有/共享 | 是否GC | 会否OOM | 主要存储 | 关键参数 |
|---|---|---|---|---|---|
| 程序计数器 | 私有 | 否 | 否 | 字节码指令地址 | 无 |
| Java虚拟机栈 | 私有 | 否 | 是 | 栈帧（局部变量表等） | -Xss |
| 本地方法栈 | 私有 | 否 | 是 | Native方法信息 | 平台相关 |
| 堆内存 | 共享 | 是 | 是 | 对象实例、数组 | -Xms、-Xmx |
| 方法区/元空间 | 共享 | 是 | 是 | 类信息、常量、静态变量 | -XX:MetaspaceSize |
| 直接内存 | 共享 | 否 | 是 | NIO缓冲区 | -XX:MaxDirectMemorySize |
5.4 JVM内存演进时间线
timeline
title JVM内存模型演进历程
section JDK 1.2-1.6
经典分代模型 : 新生代 : 老年代 : 永久代
section JDK 1.7
过渡期 : 字符串常量池移至堆 : 永久代逐步去除
section JDK 1.8+
现代模型 : 新生代 : 老年代 : 元空间(本地内存)
section 未来趋势
ZGC/Shenandoah : 低延迟GC : 统一内存管理
5.5 内存调优核心要点
堆内存调优
- 新生代大小：
-XX:NewRatio=2（老年代:新生代=2:1） - Eden与Survivor比例：
-XX:SurvivorRatio=8（Eden:S0:S1=8:1:1） - 对象晋升阈值：
-XX:MaxTenuringThreshold=15
栈内存调优
- 栈大小：
-Xss1m（根据递归深度调整） - 线程数量：栈大小 × 线程数 ≤ 可用内存
元空间调优
- 初始大小：
-XX:MetaspaceSize=256m - 最大限制：
-XX:MaxMetaspaceSize=1g - 压缩指针：
-XX:+UseCompressedOops（默认开启）
5.6 常见内存问题诊断
flowchart LR
A[内存问题] --> B{异常类型}
B -->|OutOfMemoryError: Java heap space| C[堆内存不足]
B -->|OutOfMemoryError: Metaspace| D[元空间不足]
B -->|StackOverflowError| E[栈溢出]
B -->|OutOfMemoryError: Direct buffer memory| F[直接内存不足]
C --> G[增大-Xmx<br/>检查内存泄漏<br/>优化对象生命周期]
D --> H[增大MetaspaceSize<br/>减少动态类生成<br/>检查类加载器泄漏]
E --> I[增大-Xss<br/>优化递归算法<br/>检查无限递归]
F --> J[增大MaxDirectMemorySize<br/>优化NIO使用<br/>及时释放DirectBuffer]
5.7 性能监控关键指标
| 监控维度 | 关键指标 | 工具推荐 | 正常范围 |
|---|---|---|---|
| 堆使用率 | Heap Utilization | JVisualVM, JProfiler | < 80% |
| GC频率 | Minor GC/Major GC次数 | GCViewer, GCPlot | 根据业务调整 |
| GC停顿 | STW时间 | GC日志分析 | < 100ms |
| 元空间 | Metaspace使用量 | JConsole | 稳定增长 |
| 线程栈 | 线程数量 | JStack | < 1000 |
以上内容通过系统化架构图+演进时间线+对比表格全面呈现JVM运行时数据区的完整体系，涵盖了程序计数器、虚拟机栈、本地方法栈、堆内存、方法区/元空间的详细分析，以及内存调优和问题诊断的实践指导，为深入理解JVM内存管理提供了完整的理论基础和实战经验。
