Java虚拟机之堆空间

目录

核心概述

内存细分

堆空间大小的设置

java.lang.OutOfMemoryError: Java heap space

新生代与老年代

对象分配过程

常用的调优工具

Minor GC、Major GC与Full GC

堆空间的分代思想

TLAB(Thread Local Allocation Buffer)

堆空间常用参数设置小结

逃逸分析-


核心概述

一个JVM实例值存在一个堆内存,堆也是Java内存管理的核心区域。

Java堆区在JVM启动的时候就被创建了,其空间大小也就确定了,是JVM管理的最大一块内存空间。

《Java虚拟机规范》规定,堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的。

所有的线程共享Java堆,在这里还可以划分线程私有的缓冲区(TLAB,Thread Local Allocation Buffer)。

《Java虚拟机规范》中对Java堆的描述是:所有的对象实例以及数组都应当在运行时分配在堆上(但并不是全部)。

数组和对象可能永远不会存储在栈上,因为栈帧中保存引用,这个引用指向对象或者数组在堆中的位置。

在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除。

堆,是GC(垃圾收集器)执行垃圾回收的重点区域。

内存细分

现代垃圾收集器大部分都是基于分代收集理论设计,堆空间细分为:

 虽然说,逻辑上是将堆空间划分为新生代、老年代和永久代三部分,实际上是不考虑永久代(也就是Java8中提到的元空间)的,可以将其看做是方法区的落地实现。

Java8的变化

 

堆空间大小的设置

Java堆区用于存储Java对象实例,那么堆的大小在JVM启动的时候就已经设定好了,大家可以通过选项“-Xmx”和“-Xms”来进行设置,其中-X是JVM的运行参数。

  • “-Xms”用于表示堆区(年轻代+老年代,不包括元空间)的起始内存(ms:memory start),等价于-XX:InitialHeapSize
  • “-Xmx”则用于表示堆区的最大内存,等价于-XX:MaxHeapSize
添加 -XX:+PrintGCDetails 运行参数,代码执行后会在控制台输出堆空间情况

一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时,将会抛出OutOfMemoryError异常。

通常会将-Xms和-Xmx两个参数配置相同的值,其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小,从而提高性能。(详细可参考https://blog.csdn.net/u010900754/article/details/86629240

默认情况下,初始内存大小:物理电脑内存大小 / 64

                      最大内存大小:物理电脑内存大小 / 4

java.lang.OutOfMemoryError: Java heap space

当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时,就会抛出error(注:非exception,因为这个问题已经严重到不足以被应用处理)——OutOfMermoryError。按照JVM规范,除了程序计数器不会抛出OOM外,其他各个内存区域都可能会抛出OOM,其中最为常见的情况就是java堆内存溢出,一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露,需要通过内存监控软件查找程序中的泄露代码,而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。

新生代与老年代

存储在JVM中的Java对象可以被划分为两类:

  • 一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常迅速。
  • 另外一类对象的生命周期却非常长,在某些极端的情况下还能够与JVM的生命周期保持一致。

Java堆区进一步细分的话,可以划分为年轻代和老年代,其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间(有时也叫做from区和to区)

 下面这参数开发中一般不会调:

配置新生代和老年代在堆结构的占比:

  • 默认-XX:NewRatio=2,表示新生代占1,老年代占2,新生代占整个堆的1/3
  • 可以修改-XX:NewRatio=4,表示新生代占1,老年代占4,新生代占整个堆的1/5
  • 查询当前占比:jinfo -flag NewRatio 进程号
  • 在HotSpot中,Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1,开发人员可以通过-XX:SurvivorRatio调整这个空间比例。这里注意一点,虽然默认比例是8:1:1,但是JDK 1.8 默认使用 UseParallelGC 垃圾回收器,该垃圾回收器默认启动了 AdaptiveSizePolicy(自适应大小策略),所以实际上年轻代三个区域之间的比例仍会变动。详情可参考https://www.jianshu.com/p/7414fd6862c5
  • 可以使用-Xmn设置新生代的空间的大小,注意命令的意思是将NewSize与MaxNewSize设为一致。如果同时添加了-Xmn和-XX:NewRatio参数,则以-Xmn为准。

几乎所有的Java对象都是在Eden区被new出来的,绝大部分的Java对象销毁都在新生代进行了。 

对象分配过程

为新对象分配内存是一件非常严谨和复杂的任务,JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题,并且由于内存分配算法与内存回收算法密切相关,所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。

1. new 的对象先放在Eden区,此区有大小限制。

2. 当Eden区的空间填满时,程序又需要创建对象,JVM的垃圾回收机制将对Eden区进行垃圾回收(MinorGC,也成YoungGC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到Eden区。

3. 然后将Eden区中的剩余对象转移到Survivor0区。

红色:不再被其他对象所引用,销毁;绿色:幸存者,放到S0

4. 如果再次触发垃圾回收,此时上次幸存下来的放到Survivor0区的同样被执行垃圾回收,剩下的没有被回收的就会连同Eden区的幸存者一起放到Survivor1区。(注意:S1和S0 是被动的垃圾回收,当Eden区触发MinorGC的时候会顺带判断幸存区的对象,其本身不会触发,那如果满了怎么办呢?这个时候有一个担保机制,直接将新创建的对象放到老年代)

5. 如果再次经历垃圾回收,此时会重新放回到Survivor0区,接着再去Survivor1区。

6. 那么什么时候才能去老年代区呢?可以设置次数(阈值),默认是15次,也就是说,如果一个对象,经历了15次MinorGC,就将其晋升到老年代。设置参数:  -XX:MaxTenurningThreshold:<N>进行设置。此外,还有一个动态对象年龄判断问题,就是说如果Survivor区中相同年龄大小的所有对象大小总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代,无需等到MaxTenurningThreshold中要求的年龄。动态对象年龄判断主要是被TargetSurvivorRatio这个参数来控制。而且算的是年龄从小到大的累加和,而不是某个年龄段对象的大小,看下面这个场景

  1. MaxTenuringThreshold为15
  2. 年龄1的对象占用了33%
  3. 年龄2的对象占用33%
  4. 年龄3的对象占用34%。

年龄1的占用了33%,年龄2的占用了33%,累加和超过默认的TargetSurvivorRatio(50%),年龄2和年龄3的对象都要晋升。

总结 

  • 关于幸存者S1、S0区:复制之后有交换,谁空谁是to。(一GC一交换,谁0谁是to)
  • 关于垃圾回收:频繁在新生区收集,很少在老年区收集,几乎不在永久区/元空间收集

基于以上描述,我们可以画图来表示整个的流程:

 

如果老年区也放不下了,就会报OOM的异常,这个时候会触发MajorGC。

常用的调优工具

JDK命令行(javap、jmap、jinfo)

Jconsole

VisualVM

JProfiler

Java Flight Recorder

GCViewer

GC Easy

Minor GC、Major GC与Full GC

堆空间的分代思想

为什么需要把Java堆分代?不分代就不能正常工作了吗?

经研究,不同对象的生命周期不同,70%-90%的对象是临时对象。

TLAB(Thread Local Allocation Buffer)

我们知道,堆区是线程共享区域,任何线程都可以访问到堆区的共享数据,由于对象实例的创建在JVM中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的。为了避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度,TLAB就是为了解决这一问题。

什么是TLAB?

从内存模型而不是垃圾收集的角度,对Eden区域继续进行划分,JVM为每个线程分配一个私有缓存区域,它包含在Eden空间内。

多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以将这种内存分配方式称之为快速分配策略

  • 尽管不是所有的对象实例都能够在TLAB中成功分配内存,但是JVM确实是将TLAB作为内存分配的首选。
  • 在程序中,开发人员通过"-XX:UseTLAB"设置是否开启TLAB空间(可以通过jinfo -flag UseTLAB 线程号查询是否开启)。
  • 默认情况下,TLAB空间的内存非常小,仅占有整个Eden空间的1%,可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。
  • 一旦对象在TLAB空间分配内存失败时,JVM就会尝试着通过使用加锁机制确保数据操作的原子性,从而直接在Eden空间中分配内存。
加入TLAB后的对象分配过程

 

堆空间常用参数设置小结

官网说明:https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

关于空间分配担保策略:

在发生Minor GC之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

  • 如果大于,则此次Minor GC是安全的。
  • 如果小于,则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小,如果大于,则尝试进行一次MinorGC,但这次MinorGC依然是有风险的;如果小于,则改为进行一次Full GC。如果HandlePromotionFailure=false,则改为进行一次Full GC。
  • JDK7开始,HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略,也就是说,默认HandlePromotionFailure=true,而且不可修改为false。

逃逸分析-

堆是分配对象存储的唯一选择吗?

随着JIT编译器的发展与逃逸分析技术的逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化,所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

在Java虚拟机中,对象是在Java堆中分配内存的,这是一个普遍的常识,但是,有一种特殊的情况,就是如果经过逃逸分析后发现,一个对象并没有逃逸出方法的话,那么就有可能被优化成栈上分配。这样就无需在堆上分配内存,也无需进行垃圾回收了。这也是常见的堆外存储技术。

此外,前面提到的基于OpenJDK深度定制的TaoBaoVM,其中创新的GCIH(GC invisible heap)技术实现off-heap,将生命周期较长的Java对象从heap中移到heap外,并且GC 不能管理GCIH内部的Java对象,以此达到降低GC回收频率个提升GC的回收效率的目的。

逃逸分析

如何将堆上的对象分配到栈,需要使用逃逸分析手段。

这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。

通过逃逸分析,Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

逃逸分析的基本行为就是分析对象的动态作用域:

  • 当一个对象在方法中被定义后,对象只在方法内部使用,则认为没有发生逃逸,那就使用栈上分配,随着方法执行的结束,栈空间就被移除。
  • 当一个对象在方法中被定义后,它被外部方法所引用,则认为发生逃逸。例如,作为调用参数传递到其他地方中。

几种常见的情况进行逃逸分析:

public class EscapeAnalysis {
    public EscapeAnalysis obj;
    /*
     *方法返回EscapeAnalysis对象,发生逃逸
     */
    public  EscapeAnalysis getInstance(){
        return obj == null ? new EscapeAnalysis() : obj;
    }
    /*
     *为成员属性赋值,发生逃逸
     */
    public  void setObj(){
        this.obj = new EscapeAnalysis();
    }
    /*
     * 对象的作用域尽在当前方法中有效,没有发生逃逸
     */
    public void useEscapeAnalysis(){
        EscapeAnalysis escapeAnalysis = new EscapeAnalysis();
    }
    /*
     *引用成员变量的值,发生逃逸
     */
    public void useEscapeAnalysis1(){
        EscapeAnalysis escapeAnalysis = getInstance();
    }

}

在JDK 6u23之后,HotSpot就默认开启了逃逸分析,较早的版本可以通过“-XX:+DoEscapeAnalysis”显示开启逃逸分析,“-XX: +PrintEscapeAnalysis”查看逃逸分析的筛选结果。

为了提高性能,使用逃逸分析,编译器可以对代码做如下优化:

  1. 栈上分配。将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,而不是堆分配,这就要求开发中能使用局部变量的,就不要在方法外定义。(视频讲解举例:https://www.bilibili.com/video/BV1PJ411n7xZ?p=83
  2. 同步省略。如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步。线程同步的代价是相当高的,同步额后果是降低并发性和性能。在动态编译同步块的时候,JIT编译器可以借助逃逸分析来判断同步块所使用的的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有,那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步,这个过程就叫做同步省略,也叫锁消除。(视频讲解举例:https://www.bilibili.com/video/BV1PJ411n7xZ?p=84
  3. 分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么对象的部分(或全部)可以不存储在内存,而是存储在CPU寄存器中。所谓标量,是指一个无法再分解成更小的数据的数据,Java中的原始数据类型就是标量。相对的,那些还可以分解的数据叫做聚合量。在JIT阶段,如果经过逃逸分析,发现一个对象不会被外界访问的话,那么经过JIT优化,就会把这个对象拆解成若干个成员变量来代替,这个过程就是标量替换。可以通过-XX:+EliminateAllocation开启标量替换,默认是打开的,允许将对象打散分配在栈上。(视频讲解举例:https://www.bilibili.com/video/BV1PJ411n7xZ?p=85

其实即使到如今逃逸分析技术也不是特别成熟,其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗,虽然经过逃逸分析可以以做标量替换、栈上分配和锁消除,但是逃逸分析本身也是需要进行一系列复杂的分析的。一个比较极端的例子就是,经过逃逸分析后,发现没有一个对象是不逃逸的,那这个逃逸分析的过程就白白浪费掉了。

 

 

 

 

 

 

  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值