JVM 06 第三章 part 堆

1. 堆(heap) 的核心概述
  • 一个JVM只存在一个堆内存,堆在Java内存管理的核心区域
  • Java堆区在JVM启动的时候就被创建,其空间大小也就确定了,时JVM管理的最大一块内存空间
    • 堆内存的大小是可以被调节的
  • 《Java虚拟机规范》规定,堆可以处于物理上不连续的内存空间中,但是逻辑上他应该被视为连续的。
  • 所有的线程共享Java堆,在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer, TLAB)
  • 《Java虚拟机规范》中对Java堆的描述是: 所有的对象实例以及数组都应当运行时分配在堆上。
    • ? “几乎”所有的对象实例都在这里分配内存
  • 数组和对象可能永远不会存储在栈上,因为栈帧中保存引用,这个引用指向对象或者数组在堆中的位置
  • 在方法结束后,堆中对象不会马上被移除,仅仅在垃圾收集的时候才会被移除
  • 堆,时GC(Garbage Collection,垃圾收集器)执行垃圾回收的中带你区域
内存细分

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

  • 在Java 7及其以前堆内存逻辑上分为三部分: 新生区+养老区+永久区,新生区又划分为 Eden 区和 Survivor区
  • 在Java8及其之后堆内存逻辑上划分为三部分: 新生区+养老区+云空间,新生区又划分为 Eden 区和 Survivor区
2. 设置堆内存大小与OOM
  • Java堆区用于储存Java对象实例,那么堆的大小在JVM启动时就已经设定好了,可以通过选型“-Xmx” 和"-Xms"进行设置
    • “-Xms”用于表示堆区的其实内存,等价于-XX:InitialHeapSize
    • "-Xmx"用于表式堆区中最大的内存,等价于-XX:MaxHeapSize
  • 一单堆区中的内存大小超过了Xmx所在设置的最大内存,就会抛出OutOfMemoryError异常
  • 通常将 -Xms 和-Xmx 这两个参数配置相同的值,目的是为了能够在Java回收机制清除完堆区后不需要重新分隔计算堆区的大小,从而提高性能
  • 默认情况下初始大小: 物理电脑内存大小/64
    • 最大内存: 物理电脑内存大小/4
3. 年轻代与老年代
  • 存储在JVM中的Java对象可以被划分为两类:
    • 一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常的迅速
    • 另外一类对象的生命周期却非常长,在某种极端的情况下还能够与JVM的生命周期保持一致
  • Java堆区进一步细分的话,可以划分为年轻代和老年代
  • 其中年轻代有可以划分为Eden空间和Survivor0空间和Survivor1空间(有时候也被叫做from区和to区)
  • 在默认情况下 NewRatio的比例是2
  • 配置新生代与老年代在堆结构的占比:
    • 默认-xx:NewRatio=2,表示新生代占1,老年代占2,新生代占整个堆得1/3
    • 可以修改-xx:NewRatio=4,表示新生代占4,老年代占2,新生代占整个堆得1/5
  • 在HotSpot中,Eden空间和另外两个Survivor空间缺省所占比的比例为8:1:1
    • 但是由于存在自适应调整,可能会发生变法
  • 当开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例,比例如:-XX:SurvivorRatio=8,-XX:SurvivorRatio可以调整新生代中分配比例
  • 几乎所有的Java对象都是在Eden区被new出来
  • 绝大部分的Java对象的销毁都是在新生代进行的
    • 新生代80%的对象都是朝生晚死
  • 可以使用选项“-Xmn”设置新生代最大内存大小
    • 这个参数一般使用默认值即可
4. 分配对象

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

  1. new 的对象先放在伊甸园区(Eden区) 80%,此区有内存限制
  2. 当伊甸园区的空间被填满时,程序有需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将伊甸园区中的不再被其它对象所引用的对象进行销毁,在加载新的对象放到伊甸园区。需要注意的是幸存者区 Survivor区不会触发MirrorGC,此外在进行GC的时候用户线程就停止了
  3. 然后将一段园中的剩余对象移动到Survivor0中
  4. 如果再次触发垃圾回收,此时上次幸存下来的存放到survivor 0的如果没有被回收,就会被放置在survivor1中
  5. 如果再次经历垃圾回收,此时会重新放置在survivor0区,接着再去survivor1区
  6. 什么时候才能去养老区? 可以设置次数,默认为15此
    1. 参数设置: -XX:MaxTenuringThreshold=<N>进行设置
  7. 老年代不会频繁的进行操作

总结:

  • 针对Survivor s0 s1的总结: 复制之后有交换,谁空谁为to
  • 关于垃圾回收: 频繁在新生代收集,很少在老年区收集,几乎不再永久区/原空间收集
5. Minor GC、Major GC 与Full GC

JVM在进行GC的时候,并非每次都对上面三个内存区域一起回收的,大部分的时候回收的都是指新生代

针对HotSpot VM的实现,它里面的GC按照回收区域又划分为两大类型:一种是部分收集,一种是整堆收集。

  • 部分收集(Partial GC): 不是完整收集整个Java堆的垃圾收集,其中又分为:
    • 新生代收集(Minor GC 或者是Yong GC): 只是新生代的垃圾收集
    • 老年代收集(Major GC/Old GC):只是老年代的垃圾收集。
      • 目前 只有CMS GC会有单独收集老年代的行为。
      • 注意: 很多时候Major GC会和 Full GC混淆使用,需要具体分辨是老年代回收还是整堆回收
    • 混合收集(Mix GC)收集整个新生代以及部分老年代的垃圾收集
      • 目前,只有G1 GC会有这种行为
  • 整堆收集(Full GC):手机整个Java堆和方法区的垃圾收集
新生代GC ( Minor GC) 触发机制
  • 当新生代空间不足的时候就会触发Minor GC,这里的新生代满指的是Eden区空间满,Survivor 满的时候不会触发GC,每次Minor GC 都会清理新生代的内存
  • 因为Java对象大多数都具有朝生夕亡的特征,所以Minor GC非常频繁,一般回收速度也比较快。
  • Minor GC会引发STW,暂停其他用户的线程,等垃圾回收结束后,用户线程才会恢复
老年代GC触发机制(Major GC/old 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错误
  • Major GC 的速度一般会比 Minor GC的速度慢上10倍以上
Full GC 触发机制

出发Full GC 执行情况有以下5中:

  1. 直接调用System.gc()方法时,系统建议执行Full GC但是不是必然执行
  2. 老年代空间不足
  3. 方法去空间不足
  4. 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
  5. 由Eden 区、survivor space0 (From)向Survivor space1(To)区进行复制的时候,对象大于To区可调用的内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小

Full GC是开发或者调优过程中尽量要避免的,这样暂停的时间会短一些

堆空间分代思想
为什么需要把Java堆分代?部分带就不能正常工作了吗
  • 经研究表明,不同对象的生命周期不同,70%-99%的对象都是临时对象
    • 新生代: 由Eden、两块大小相等的Survivor(又称作 from/to s0/s1)构成,其中,to区为0
    • 老年代:存放在新生代中经历过多次CG回收依然存活的对象
  • 其实不分代也可以,分代的唯一理由就是优化GC性能,如果没有分代,那所有的对象都放在了一起,,GC在回收过程中好需要进行扫描。如果分代的话能够减少扫描的时间。
6. 内存分配从策略
针对不同年龄段的对象分配原则:
  • 优先分配到Eden区
  • 大对象直接分配到老年代
    • 尽量避免程序中出现过多的大对象
  • 长期存活的对象分配到老年代
  • 动态对象年龄判断:
    • 如果Survivor区中年龄相等的所有对象大小的综合大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入到老年代,无需等到MaxTenuringThreshold 中要求的年龄
  • 空间分配担保:
    • -XX:HandlePromotionFailure
7. 为对象分配内存: TLAB 本地线程缓冲
为什么有TLAB(Thread Loacl Allocation Buffer)?
  1. 堆区是线程共享区域,任何线程都可以访问到堆区中的共享数据
  2. 由于对象实例的创建在JVM中非常频繁,因此在并发环境下从对区中划分内存空间是线程不安全的
  3. 为了避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度
什么是TLAB?
  • 从内存模型而不是垃圾收集的角度,堆Eden区域继续进行了划分,JVM为每个线程分配了一个私有的缓存区域,它包含在Eden区域内
  • 多线程同时分配内存时,使用TLAB可以直接避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以直接将这种内存分配方式称之为最快分配策略
  • OpenJDK衍生出来的JVM都提供了TLAB设计
TLAB 再声名:
  • 尽管不是所有的对象实例都能够在TLAB中成功分配内存,但是JVM确实是将TLAB最为了内存分配的首选
  • 在程序中,开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
  • 默认情况下,TLAB空间的内存非常小,进展有整个Eden空间的1%,当然也可以通过选项"-XX:TLABWasteTargetPercent"设置TLAB占用Eden空间的百分比大小
  • 一旦对象在TLAB空间分配内存失败,JVM就会尝试通过使用加锁机制确定数据操作的原子性,从而直接在Eden空间中直接分配内存。
8. 逃逸
1. 逃逸分析的概述
  • 通过逃逸分析的手段能够将堆上的对象找到栈。
  • 这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法
  • 通过逃逸分析,Java HotSpot 编译器能够分析出一个新的对象的引用的适用范围从而决定是否要将这个对象分配到堆上
  • 逃逸分析的基本行为就是分析对象动态作用域:
    • 当一个对象在方法中被定义后,对象值在方法内部使用,则认为没有发生逃逸
    • 当一个独享在方法中被定义后,他被外部方法所引用,则认为发生逃逸,例如作为调用参数传递到其他地方
2. 代码优化
  1. 栈上分配

    将堆分配转换为栈分配,如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,而不是堆分配

    通过开启栈上分配,无法逃逸的就直接在栈上进行分配内存,再分配过程中不会出现CG,能够提高运行速度

  2. 同步省略

    如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步

    • 线程同步的代价是非常高的,同步的后果是降低并发性和性能
    • 在动态编译器同步块的时候,JIT编译器(同步编译器)可以通过借助逃逸分析来判断同步块所使用的锁对象是否只能被一个线程访问而不能被发布到其他线程上。如果没有,那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样能大大提高并发行和性能,这个取消同步的过程就叫做同步省略,也叫做锁清除。
  3. 分离对象或标量替换

    有的对象可能需要作为一个连续的内存结构存在,也可以北方问道,那么对象的部分或者全部可以不存储在内存,而是存储在栈中

    • 标量是指一个无法在分解成更小的数据单位,Java中的原始数据类型就是标量。
    • 相对的,那些还可以分解的数据叫做聚合量,Java中的对象就是聚合量,因为他可以分解成其他聚合量的标量
    • 在JIT阶段,如果经过逃逸分析,发现一个对象不会被外界访问的话,那么经过JIT优化,就会把这些对象拆解成若干个成员变量来代替,这个过程就是标量替换
逃逸技术并不成熟:

逃逸技术并不成熟的根本原因是:无法保证逃逸分析的性能消耗一定高于其他的消耗,虽然经过逃逸分析可以做标量替换、栈上分配、锁清除,但是逃逸分析自身也需要进行一些列复杂的分析,这其实也是一个相对耗时的过程

虽然并不成熟,但是它也是即时编译器优化技术中一个十分重要的手段

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值