理解Java内存区域与垃圾收集器

1,924 阅读13分钟

本文目录结构

  • java内存区域
    • 运行时内存区域
    • 对象访问
  • 垃圾收集器
    • 判断对象死亡
    • 方法区回收
    • GC回收算法
    • 空间分配担保
  • 参考

java内存区域

运行时内存区域

java虚拟机在执行java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。

java内存区域
我们注意到运行时区域主要会包括5部分区域,它们有个各自的用途,以及创建和销毁时间,有的依赖虚拟机进程,有的依赖用户线程。

  • 程序计数器 程序计数器是一块较小的内存空间,它的作用是当前线程所执行到的字节码的位置指示器。字节码解释器工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令,从而达到分支、循环、跳转、异常处理等基本功能。 java虚拟机中的多线程实际是通过线程轮流切换实现的。所以实际上在同一时刻,处理器的一个内核只会执行一条指令。因此为了线程切换后还能恢复到正确的执行位置,需要每个线程都要有一个独立的程序计数器。而且他们之间互补影响,独立工作。所以程序计数器是一块线程私有的内存。
  • 本地方法栈 与程序计数器一样,本地方法栈也是线程私有的。本地方法栈为虚拟机提供使用Native方法服务。由于虚拟机规范并没有对本地方法栈中的使用语言和数据结构等做强制规定,所以虚拟机可以自由实现。
  • java虚拟机栈 同本地方法栈,虚拟机栈是线程私有,它的生命周期与当前线程相同。它为虚拟机执行java方法提供服务。它描述的内存模型:每个方法被执行的时候会同时创建一个栈桢,用于存储局部变量、操作栈、动态链接、方法出口等信息。每个方法的调用到返回结果的过程,就是对应一个栈桢的入栈与出栈。 经常有人会说java内存可以粗糙的区分为堆和栈,这里的栈就是虚拟机栈,而虚拟机栈中最重要的就是局部变量表。 局部变量表存放了编译期可知的基本数据类型、对象的引用(reference类型,它可能只想对象起始地址的引用指针,也可能指向代表改对象的句柄)。局部变量表所需要的内存在编译期完成分配,当进入一个方法时,此方法所需要的内存空间大小是确定的,所以在方法运行期间,不会改变局部变量表的大小。
  • java堆 对于虚拟机来说,堆是其所管理的最大的一块内存。java堆是指被线程共享的一块内存区域,它在虚拟机启动时即创建,堆的唯一目的时存放对象实例。同时由于堆空间有限,对象的创建和销毁是时常发生的,所以java堆是垃圾收集器的主要管理区域,所以java堆有时也会称为GC堆。现在的GC回收基本都采用分代回收算法,所以堆可以细分为新生代和老年代,新生代又可以分为eden区,from Survivor空间和to Survivor空间等。对于堆中的各个区域分配和回收细节,在GC部分讲解。 在虚拟机规范中,没有强制要求堆是物理内存连续的,只是逻辑上连续即可。所以当前的主流虚拟机的堆空间都是可以动态扩容的,可以通过-Xmx和-Xms控制。
  • 方法区 方法区同java堆都是线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。java虚拟机实现规范对该区域并没有强制要求实现GC回收,所以相对而言,该区域的垃圾收集器很少出现,所以有人开发者会成称该区域为永久代。这个区域的内存回收主要是针对常量池的回收和对类型的卸载。 运行时常量池 一个class文件除了有类的版本、字段、方法、接口等描述以外,还有一项是常量池,用于存放编译期间生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。运行时常量池是具有动态性的,java虚拟机对class文件的每一部分的格式有严格的规定,每个字节用于存储哪种数据都有规范要求,这样才会被虚拟机认可。但是对于常量池是比较宽松的,因为java并不要求常量一定要编译期产生,也可以在运行期间放入常量,比如String的intern()方法。

对象访问

在java虚拟机栈中我们提到局部变量表存放了对象的引用,我们都知道对象是分配的java堆中的,那么具体是怎么引用的呢? 比如Object obj = new Object();,假设这句代码出现在方法体中,那么“Object obj ”这部分语义将会反映到java栈的本地变量表中(为reference类型),而“new Object()”这部分语义将会反映在java堆上,形成一块存储了Object类型所有实例数据值的结构化内存。 由于reference类型在java虚拟机规范中只规定了一个指向对象的引用,所以在实际虚拟机中访问会有所不同,主流访问有两种:

  • 句柄访问
  • 直接指针访问
句柄访问

java堆会划分出一小块内存空间作为句柄池,reference中存储的就是对象的句柄地址,二句柄中包含了对象实例数据和类型数据的各自地址信息。

image.png

直接地址访问

reference中直接存储的就是对象的地址,java堆需要考虑对象的布局中如何存放访问类型数据的相关信息。

image.png
这两种对象的访问方式各有优势,使用句柄访问方式的最大好处就是reference中存储的是稳定的句柄地址,在对象被移动时只会改变句柄中的实例数据指针,而reference本身不需要被修改。使用直接指针访问方式的最大好处就是速度更快,它节省了一次指针定位的的时间开销。

垃圾收集器

判断对象死亡

GC在对堆内存进行回收前,第一件事是需要确定哪些对象是需要被回收的,所以就需要判断对象是否存活。一般的有两种方法来判断:

  1. 引用计数法 给一个对象添加一个引用计数器,每当有地方对其引用时,计数器加1,当引用实效时,计数器减1,任何时刻计数器为0时就表示该对象不再被使用。 引用计数法实现简单,通常是比较高效的,但是引用计数法有个弊端是当两个不再被使用的对象互相引用时,导致两者都不会被释放。
  2. 根搜索算法 根搜索算法是指通过一系列名为“GC roots"的对象为起点,从这些节点开始向下搜索,搜索过的路径称为引用链,当一个对象到GC roots没有任何引用链相连,就表示此对象不再被使用。 在java语言中,作为GC roots的对象包括以下几种: a. java虚拟机栈(栈桢中本地变量表)中引用的对象 b. 方法区中类静态属性引用的对象 c. 方法区中常量引用的对象 d. 本地方法栈中JNI引用的对象

方法区回收

前面已经提到方法区是很少出现垃圾收集器的,因为方法区回收的性价比比较低,通常堆内存的回收一次可以回收70%-95%的空间,但方法区的垃圾收集器效率很低。 一般的,方法区回收主要由两部分: 1.废弃常量 废弃的常量与堆回收比较类似,只需要指导该常量是否在其他地方被使用即可。 2.无用的类 这种情况的判断比较苛刻,一般要求满足以下三个条件才算是无用的: a. 该类的所有实例都被回收 b. 加载该类的ClassLoader也被回收 c. 该类对应的java.lang.class对象没有在任何地方被引用,无法在任何地方通过反射访问该类

GC回收算法

1.标记-清除算法 最基础的收集算法是“标记-清除”(Mark-Sweep)算法,如同它的名字一样,算法分为“标记”和“清除”两个阶段。 a. 首先标记出所有需要回收的对象 b. 在标记完成后统一回收所有被标记的对象。 缺点: 效率问题:标记和清除两个过程的效率都不高 空间问题:标记清除之后产生大量不连续的内存碎片,空间碎片太多可能会导致以后程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

标记-清除算法

2.复制算法 目的是为了解决效率问题。 将可用内存按容量大小划分为大小相等的两块,每次只使用其中的一块。当一块内存使用完了,就将还存活着的对象复制到另一块上面,然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况。 缺点: 将内存缩小为了原来的一半。

复制算法
现代的商业虚拟机都采用这种收集算法来回收新生代,IBM公司的专门研究表明,新生代中对象98%对象是“朝生夕死”的,所以不需要按照1:1的比例来划分内存空间,而是将内存分为较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。

3.标记-整理算法 复制收集算法在对象存活率较高时,就要进行较多的复制操作,效率就会变低。 根据老年代的特点,提出了“标记-整理”算法。 标记过程仍然与”标记-清除“算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉边界以外的内存。

标记-整理算法

4.分代收集算法 一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法。在老年代中,因为对象存活率高、没有额外空间对它进行分配担保,就必须采用“标记-清除”或“标记-整理”算法来进行回收。JVM把年轻代分为了三部分:1个Eden区和2个Survivor区(分别叫from和to),默认比例为8:1。 工作过程:一般情况下,新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次GC后,如果仍然存活,将会被移到Survivor区。对象在Survivor区中每熬过一次GC,年龄就会增加1岁,当它的年龄增加到一定程度时,就会被移动到年老代中。 因为年轻代中的对象基本都是朝生夕死的(80%以上),所以在年轻代的垃圾回收算法使用的是复制算法,复制算法不会产生内存碎片。在GC开始的时候,对象只会存在于Eden区和名为“From”的Survivor区,Survivor区“To”是空的。紧接着进行GC,Eden区中所有存活的对象都会被复制到“To”,而在“From”区中,仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值,可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中,没有达到阈值的对象会被复制到“To”区域。经过这次GC后,Eden区和From区已经被清空。这个时候,“From”和“To”会交换他们的角色,也就是新的“To”就是上次GC前的“From”,新的“From”就是上次GC前的“To”。不管怎样,都会保证名为To的Survivor区域是空的。GC会一直重复这样的过程,直到“To”区被填满,“To”区被填满之后,会将所有对象移动到年老代中。

空间分配担保

先了解下Minor GC与Major GC/Full GC

  • Minor GC 即新生代GC,指发生在新生代的垃圾收集动作,Minor GC的回收的对象大多具备朝生夕灭的特性,所以Minor GC是非常频繁,并且回收速度比较快。
  • Major GC/Full GC 即老年代GC,指发生在老年代的垃圾收集动作,出现Major GC,经常会伴随至少一次的Minor GC。Major GC的速度一般比Minor GC慢10倍以上。

在发生Minor GC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于,则改为直接进行一次Full GC,如果小于,则查看HandlePromotionFailure设置是否允许担保失败,如果允许,那么只会进行Minor GC,如果不允许,那么进行一次Full GC。 在分代回收算法中提到过,新生代使用复制收集算法,但为了内存利用率,只使用其中一个Survivor空间来作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况(最极端的情况就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,把Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似,老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的,所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值,与老年代的剩余空间进行比较,决定是否进行Full GC来让老年代腾出更多空间。

参考

@Dpuntu, 本文版权属于再惠研发团队,欢迎转载,转载请保留出处。