JVM内存划分

JVM的内存划分中,有部分区域是线程私有的,有部分是属于整个JVM进程;有些区域会抛出OOM异常,有些则不会,了解JVM的内存区域划分以及特征,是定位线上内存问题的基础。那么JVM内存区域是怎么划分的呢?

运行中的Java进程内存占用情况

1. Java内存区域

1.1 程序计数器(Program Counter Register)

首先是程序计数器(Program Counter Register),简称PC,在JVM规范中,每个线程都有自己的程序计数器。
这是一块比较小的内存空间,存储当前线程正在执行的Java方法的JVM指令(或操作码)地址,即字节码的行号。如果当前方法是 native 方法,那么程序计数器的值为 undefined。

该内存区域是唯一一个在Java虚拟机规范中没有规定任何OOM情况的内存区域。

1.2 Java虚拟机栈(Java Virtal Machine Stack)

第二,Java虚拟机栈(Java Virtal Machine Stack),同样也是属于线程私有区域,该区域存储着局部变量表,编译时期可知的各种基本类型数据、对象引用、方法出口等信息。
java栈总是和线程关联在一起,每当创建一个线程时,JVM就会为这个线程创建一个对应的java栈。
在这个java栈中又会包含多个栈帧,每运行一个方法就创建一个栈帧,用于存储局部变量表、操作栈、方法返回值等。每一个方法从调用直至执行完成的过程,就对应一个栈帧在java栈中入栈到出栈的过程。
每次方法调用时,一个新的栈帧创建并压栈到栈顶。当方法正常返回或抛出未捕获的异常时,栈帧就会出栈。除了栈帧的压栈和出栈,栈不能被直接操作。所以可以在堆上分配栈帧,并且不需要连续内存。

栈可以是动态分配也可以固定大小。
如果线程请求一个超过允许范围的空间,就会抛出一个StackOverflowError。
如果线程需要一个新的栈帧,但是没有足够的内存可以分配,就会抛出一个 OutOfMemoryError。

1.3 本地方法栈(Native Method Stack)

第三,本地方法栈(Native Method Stack)与虚拟机栈类似,本地方法栈是在调用本地方法时使用的栈,每个线程都有一个本地方法栈。

1.4 堆(Heap)

第四,堆(Heap),几乎所有创建的Java对象实例,都是被直接分配到堆上的。这块是GC的主要区域。
堆被所有的线程所共享,在堆上的区域,会被垃圾回收器做进一步划分,例如新生代、老年代的划分。
Java虚拟机在启动的时候,可以使用 Xms Xmx 之类的参数指定堆区域的大小。

1.5 方法区(Method Area)

第五,方法区(Method Area)。方法区与堆一样,也是所有的线程所共享。
存储被虚拟机加载的元(Meta)数据,包括类信息、构造函数、常量池、静态变量、即时编译器编译后的代码等数据。
这里需要注意的是运行时常量池也在方法区中。
根据Java虚拟机规范的规定,当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。由于早期HotSpot JVM的实现,将CG分代收集拓展到了方法区,因此很多人会将方法区称为永久代。Oracle JDK8中已永久代移除永久代,同时增加了元数据区(Metaspace)。

虽然JVM规范把方法区描述为堆的一个逻辑部分,但它却有个别名non-heap(非堆),所以大家不要搞混淆了。方法区还包含一个运行时常量池。

1.6 运行时常量池(Run-Time Constant Pool)

第六,运行时常量池(Run-Time Constant Pool),这是方法区的一部分,受到方法区内存的限制,当常量池无法再申请到内存时,会抛出OutOfMemoryError异常。
常量池主要存放两大类常量:
(1)字面量(Literal),如文本字符串、final常量值
(2)符号引用,存放了与编译相关的一些常量,因为Java不像C++那样有连接的过程,因此字段方法这些符号引用在运行期就需要进行转换,以便得到真正的内存入口地址。

class文件中的常量池,也称为静态常量池,JVM虚拟机完成类装载操作后,会把静态常量池加载到内存中,存放在运行时常量池。

1.7 直接内存(Direct Memory)

第七,直接内存(Direct Memory),直接内存并不属于Java规范规定的属于Java虚拟机运行时数据区的一部分。
Java的NIO可以使用Native方法直接在java堆外分配内存,使用DirectByteBuffer对象作为这个堆外内存的引用。

1.8 Java SE 7 规范的典型的 JVM 核心内部组件

 Java SE 7 规范的典型的 JVM 核心内部组件

2. OOM可能发生在哪些区域上?

内存区域 是否线程私有 是否可能发生OOM
程序计数器
虚拟机栈
本地方法栈
方法区
直接内存

根据javadoc的描述,OOM是指JVM的内存不够用了,同时垃圾收集器也无法提供更多的内存。从描述中可以看出,在JVM抛出OutOfMemoryError之前,垃圾收集器一般会出马先尝试回收内存。
从上面分析的Java数据区来看,除了程序计数器不会发生OOM外,哪些区域会发生OOM的情况呢?

2.1 堆内存 

第一,堆内存。堆内存不足是最常见的发送OOM的原因之一,如果在堆中没有内存完成对象实例的分配,并且堆无法再扩展时,将抛出OutOfMemoryError异常,抛出的错误信息是“java.lang.OutOfMemoryError:Java heap space”。当前主流的JVM可以通过-Xmx-Xms来控制堆内存的大小,发生堆上OOM的可能是存在内存泄露,也可能是堆大小分配不合理。

2.2 Java虚拟机栈和本地方法栈

第二,Java虚拟机栈和本地方法栈,这两个区域的区别不过是虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则为虚拟机使用到的Native方法服务,在内存分配异常上是相同的。在JVM规范中,对Java虚拟机栈规定了两种异常:1.如果线程请求的栈大于所分配的栈大小,则抛出StackOverFlowError错误,比如进行了一个不会停止的递归调用;2. 如果虚拟机栈是可以动态拓展的,拓展时无法申请到足够的内存,则抛出OutOfMemoryError错误。

2.3 直接内存

第三,直接内存。直接内存虽然不是虚拟机运行时数据区的一部分,但既然是内存,就会受到物理内存的限制。在JDK1.4中引入的NIO使用Native函数库在堆外内存上直接分配内存,但直接内存不足时,也会导致OOM。

2.4 方法区

第四,方法区。随着Metaspace元数据区的引入,方法区的OOM错误信息也变成了“java.lang.OutOfMemoryError:Metaspace”。对于旧版本的Oracle JDK,由于永久代的大小有限,而JVM对永久代的垃圾回收并不积极,如果往永久代不断写入数据,例如String.Intern()的调用,在永久代占用太多空间导致内存不足,也会出现OOM的问题,对应的错误信息为“java.lang.OutOfMemoryError:PermGen space”

3. 堆内存结构是怎么样的?

站在垃圾收集器的角度来看,可以把内存分为新生代与老年代。内存的分配规则取决于当前使用的是哪种垃圾收集器的组合,以及内存相关的参数配置。
往大的方向说,对象优先分配在新生代的Eden区域,而大对象直接进入老年代。

可以借助一些工具来了解JVM的内存内容,具体到特定的内存区域,应该用什么工具去定位呢?
图形化工具。图形化工具的优点是直观,连接到Java进程后,可以显示堆内存、堆外内存的使用情况,类似的工具有JConsole,jvisualvm 等。
命令行工具。这类工具可以在运行时进行查询,包括jstat,jmap等,可以对堆内存、方法区等进行查看。定位线上问题时也多会使用这些工具。jmap也可以生成堆转储文件(Heap Dump)文件,如果是在linux上,可以将堆转储文件拉到本地来,使用Eclipse MAT进行分析,也可以使用jhap进行分析。

3.1 新生代(Young Generation)的Eden区域

第一, 新生代的Eden区域,对象优先分配在该区域,同时JVM可以为每个线程分配一个私有的缓存区域,称为TLAB(Thread Local Allocation Buffer),避免多线程同时分配内存时需要使用加锁等机制而影响分配速度。TLAB在堆上分配,位于Eden中。TLAB的结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ThreadLocalAllocBuffer: a descriptor for thread-local storage used by
// the threads for allocation.
// It is thread-private at any time, but maybe multiplexed over
// time across multiple threads. The park()/unpark() pair is
// used to make it avaiable for such multiplexing.
class ThreadLocalAllocBuffer: public CHeapObj<mtThread> {
friend class VMStructs;
private:
HeapWord* _start; // address of TLAB
HeapWord* _top; // address after last allocation
HeapWord* _pf_top; // allocation prefetch watermark
HeapWord* _end; // allocation end (excluding alignment_reserve)
size_t _desired_size; // desired size (including alignment_reserve)
size_t _refill_waste_limit; // hold onto tlab if free() is larger than this

从本质上来说,TLAB的管理是依靠三个指针:start、end、top。start与end标记了Eden中被该TLAB管理的区域,该区域不会被其他线程分配内存所使用,top是分配指针,开始时指向start的位置,随着内存分配的进行,慢慢向end靠近,当撞上end时触发TLAB refill。
因此内存中Eden的结构大体为:
 Eden结构

3.2 新生代(Young Generation)的Survivor区域

第二、新生代的Survivor区域。当Eden区域内存不足时会触发Minor GC,也称为新生代GC,在Minor GC存活下来的对象,会被复制到Survivor区域中。
Survivor区的作用在于避免过早触发Full GC。如果没有Survivor,Eden区每进行一次Minor GC都把对象直接送到老年代,老年代很快便会内存不足引发Full GC。
新生代中有两个Survivor区,两个Survivor的作用在于提高性能,避免内存碎片的出现。在任何时候,总有一个Survivor是empty的,在发生Minor GC时,会将Eden及另一个的Survivor的存活对象拷贝到该empty Survivor中,从而避免内存碎片的产生。
新生代的内存结构大体为:
 新生代的内存结构

3.3 老年代 (Old Generation)

第三、老年代。老年代放置长生命周期的对象,通常是从Survivor区域拷贝过来的对象,不过当对象过大的时候,无法在新生代中用连续内存的存放,那么这个大对象就会被直接分配在老年代上。一般来说,普通的对象都是分配在TLAB上,较大的对象,直接分配在Eden区上的其他内存区域,而过大的对象,直接分配在老年代上。

3.4 永久代

第四、永久代。如前面所说,在早起的Hotspot JVM中有老年代的概念,老年代用于存储Java类的元数据、常量池、Intern字符串等。
在JDK8之后,就将老年代移除,而引入元数据区的概念。

3.5 Vritual空间

第五、Vritual空间。前面说过,可以使用Xms与Xmx来指定堆的最小与最大空间。如果Xms小于Xmx,堆的大小不会直接扩展到上限,而是留着一部分等待内存需求不断增长时,再分配给新生代。Vritual空间便是这部分保留的内存区域。

3.6 总结

综上所述,可以画出Java堆内的内存结构大体为:
 Java堆内的内存结构

4. 常用配置

-Xms1024m 设置初始的最小堆大小1024m

-Xmx4096m 设置最大的堆大小为4096m

-Xmn1536m 设置新生代大小为1536m。
  持久代一般固定大小为64m,所以增大新生代后,将会减小年老代大小。
  此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-Xss128k 设置每个线程的堆栈大小。
  JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。
  在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

-XX:NewSize=1024 设置 新生代 Yong Generation的初始值大小

-XX:MaxNewSize=1024m 设置 新生代 Yong Generation的最大值大小

-XX:NewRatio=4 设置新生代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。默认为2,设置为4,则新生代与年老代所占比值为1:4,新生代占整个堆栈的1/5
老年代过大的时候,Full GC的时间会很长;老年代过小,则很容易触发Full GC,Full GC频率过高,这就是这个参数会造成的影响。

-XX:SurvivorRatio=4 设置新生代中Eden区与Survivor区的大小比值。
  设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个新生代的1/6

-XX:MaxPermSize=16m 设置持久代大小为16m。

-XX:MaxTenuringThreshold=0 设置垃圾最大年龄。
  如果设置为0的话,则新生代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则新生代对象会在Survivor区进行多次复制,这样可以增加对象再新生代的存活时间,增加在新生代即被回收的概论。

4.1 JVM设置Young Gen参数优先级

JVM设置Young Gen参数优先级
(1) 最高优先级: -XX:NewSize=1024m和-XX:MaxNewSize=1024m
(2) 次高优先级: -Xmn1024m (默认等效效果是:-XX:NewSize==-XX:MaxNewSize==1024m)
(3) 最低优先级:-XX:NewRatio=2

5. 常见配置汇总

5.1 堆设置

1
2
3
4
5
6
-Xms:初始堆大小
-Xmx:最大堆大小
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4
-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5
-XX:MaxPermSize=n:设置持久代大小

5.2 收集器设置

1
2
3
4
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置并行年老代收集器
-XX:+UseConcMarkSweepGC:设置并发收集器

5.3 垃圾回收统计信息

1
2
3
4
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename

5.4 并行收集器设置

1
2
3
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

5.5 并发收集器设置

1
2
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数

6. 调优总结

6.1 年轻代大小选择

 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择)。在此种情况下,年轻代收集发生的频率也是最小的。同时,减少到达年老代的对象。
吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度。因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用。

6.2 年老代大小选择

响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了,可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间。最优化的方案,一般需要参考以下数据获得:
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间,一般会提高应用的效率

吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象。

6.3 较小堆引起的碎片问题

因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、清除方式进行回收。如果出现“碎片”,可能需要进行如下配置:

1
2
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

References

[1] 关于JVM内存的N个问题
[2] JVM内幕:Java虚拟机详解
[3] JVM结构、GC工作机制详解
[4] Java虚拟机详解—-JVM常见问题总结
[5] Java中JVM原理详解
[6] JVM 的 工作原理,层次结构 以及 GC工作原理
[7] JVM理解其实并不难!
[8] 全面理解Java内存模型
[9] 全面理解Java内存模型(JMM)及volatile关键字
[10] JVM内存模型
[11] JVMM调优总结 -Xms -Xmx -Xmn -Xss
[12] JVM设置Young Gen大小