目录
位置图解
堆的简介
堆空间中关于对象创建和GC
堆的细分内存结构
堆空间大小设置和查看
查看设置的参数
OOM异常说明与举例
新生代与老年代相关参数设置
图解对象分配的一般过程
对象分配过程概述
对象分配的特殊情况
放大招:代码举例与JVisualVM演示对象分配过程
总结内存分配策略
通过逃逸分析看堆空间的分配策略
如果Eden区过大或者过小会怎样
MinorGC、MajorGC、FullGC对比
三种GC简介
最简单的分代式GC策略触发条件
GC举例与日志分析
体会堆空间的分代思想
为什么需要把Java堆分代?不分代就不能正常工作了吗?
堆空间为每个线程分配的TLAB
什么是TLAB
为什么有TLAB(Thread Local Allocation Buffer)
对象分配过程:TLAB
堆空间的参数设置
位置图解
堆的简介
记住一个口诀:堆管存储,栈管运行
一个进程对应一个JVM实例,一个JVM实例,就对应一个运行时数据区(用了单例模式,饿汉式),一个运行时数据区对应一个方法区和一个堆。一个进程有多个线程,则这多个线程就共享一个堆空间和一个方法区(即红色部分),每个线程就各自拥有一套程序计数器、本地方法栈、虚拟机栈(即灰色部分)。
- 一个JVM实例只存在一个堆内存,堆也是Java内存管理的核心区域。
- Java堆区在JVM启动的时候即被创建,其空间大小也就确定了,是JVM管理的最大一块内存空间。堆的内存大小是可以调节的。
- 根据《Java虚拟机规范》的规定,Java堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的。
- 所有线程共享Java堆,在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer,TLAB)
- 在《Java虚拟机规范》中对Java堆的描述是:“所有的对象实例以及数组都应当在堆上分配”,而这里的“几乎”是指从实现角度来看。
- 数组和对象永远不会存储在栈上,因为栈针中保存引用,这个引用指向对象或者数组在堆中的位置
- 在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除。
- 堆,是GC(Garbage Collection,垃圾收集器)执行垃圾回收的重点区域。
堆空间中关于对象创建和GC
写一段代码来举例:
//一个简单的SimpleHeap类
public class SimpleHeap {
//成员变量
private int id;
//构造方法
public SimpleHeap(int id){
this.id = id;
}
//普通方法
public void show(){
System.out.println("My ID is" + id);
}
//main方法
public static void main(String[] args) {
//局部变量s1和s2
SimpleHeap s1 = new SimpleHeap(1);
SimpleHeap s2 = new SimpleHeap(2);
int[] arr = new int[10];
Object[] arr1 = new Object[10];
}
}
堆的细分内存结构
JDK1.7及以前:
- 新生区 Young Generation Space
- 又被划分为 Eden区 和 Survivor区
- 养老区 Tenure Generation Space
- 永久区 Permanent Space
JDK1.8及以后:
- 新生区 Young Generation Space
- 又被划分为 Eden区 和 Survivor区
- 养老区 Tenure Generation Space
- 元空间 Meta Space
堆空间大小设置和查看
Java堆区用于存储Java对象和实例,那么堆的大小在JVM启动时就已经设定好了,可以通过 “-Xms” 和 “-Xmx” 来进行设置
- “-Xms” 用于表示堆区的其实内存,等价于 -XX:InitialHeapSize
- “-Xmx” 则用于表示堆区的最大内存,等价于-XX:MaxHeapSize
一旦堆区的内存大小超过了 “-Xmx” 所指定的最大内存,将会抛出OutOfMemoryError异常(OOM)。
通常会将 -XMS 和 -Xmx 两个参数配置相同的值,其目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小,从而提高性能。开发中建议xms和xmx设置相同大小。
默认情况下,初始内存大小:物理电脑内存大小 / 64
最大内存大小:物理电脑内存大小 / 4
查看设置的参数
- 方式一:jps / jstat -gc 进程id
- 方式二:-XX:+PrintGCDetails
OOM异常说明与举例
OOM异常,可借助JVisualVM查看
新生代与老年代相关参数设置
新生代与老年代
堆空间设置大小我们已经知道了,堆空间是由年轻代与老年代构成,那么如何设置年轻代与老年代的相关参数呢?
存储在JVM中的Java可以被划分为两类:
- 一类是声明周期较短的瞬时对象,这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长,在某些极端的情况下还能够与JVM的生命周期保持一致。
Java堆区进一步细分的话,可以划分为年轻代和老年代,其中年轻代又分为:Eden区(伊甸园区),Survivor0(幸存者0区)和Survivor1(幸存者1区)。对象的最先创建的位置就是伊甸园区。
配置新生代与老年代在堆结构的占比
- 默认 -XX:NewRatio=2,表示新生代1,老年代占2,新生代占整个堆的1/3
- 可以修改-XX:NewRati0=4,表示新生代占1,老年代占4,新生代占整个堆的1/5
眼见为实,来个图让大家看看:
可以看到 Eden和S0和S1的比例并不是8:1:1,这是为什么呢?
答:这是因为自适应比例的存在:
- -XX:-UserAdaptiveSizePolicy
默认是开着的,关掉就可以了。
关了以后你会发现, 并没有任何作用,还是6:1:1。哈哈这是怎么回事呢?写成下面这个样子就行了,我们显示的指定就可以了:
- -XX:SurvivorRatio=8
你看,这不是正确了嘛!
- -XX:NewRatio 设置新生代与老年代的比例,默认值是2
- -XX:SurvivorRatio 设置新生代中Eden区与Survivor区的比例
- -XX:UseAdaptiveSizePolicy 关闭自适应的内存分配策略(暂时用不到)
- -Xmn:设置新生代的空间的大小(一般不设置)
图解对象分配的一般过程
对象分配过程概述
为对象分配内存是一件非常严谨和复杂的任务,JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题,而且由于内存分配算法与内存回收算法密切相关,所以还需要考虑GC执行完后是否会在内存空间中产生内存碎片。
- new的对象先放到伊甸园区,此区有小大限制。
- 当Eden区空间填满时,程序又需要创建对象,JVM垃圾回收器将对Eden区进行垃圾回收(Minor GC),将Eden区中的不再被其他对象所引用的对象进行销毁,再加载新的对象放到Eden区。
- 然后将伊甸园区中的声誉对象移动到S0区。
- 如果再次出发垃圾回收,此时上次幸存下来放到S0区的,如果没有回收,就会放到S1区。
- 如果再次经历垃圾回收,此时会重新放到S0区,接着再去S1区
- 啥时候能去养老区呢?可以设置次数,默认是15次。
- 参数设置:-XX:MaxTenuringThreshold
- 在养老区相对悠闲,当养老区内存不足时,再次出发Major GC,进行养老区的清理。
- 若养老区执行了Major GC之后发现依然无法进行对象的保存,就会产生OOM异常
当有一个新的对象创建之后,就放到伊甸园区。放着放着就满了,满了就会触发YGC(Y代表年轻代),没有引用指向的对象就会被清理,而绿色代表有引用指向,所以被移到幸存者区,为每个对象分配了年龄计数器,从伊甸园区放到幸存者区时,赋值为1,也就是年龄为1。此时,伊甸园区为空了。
当下一次伊甸园区满的时候,触发YGC,把绿色放到s1(因为此时s1是空的,也就是s1是to区),与此同时,判断s0中的那两个对象是否有引用指向他,有的话移到s1,并且age+1,变成了2.此时s0为空了,那么s0就是to区 。这就表示,下一次YGC的时候伊甸园区的对象要放在s0。
就这样一直循环以上内容,当age=15时,就把此对象晋升(Promotion)到老年代。15是阈值,是默认的,可以修改。
幸存者区满了之后不会触发垃圾回收。当伊甸园区满的时候触发YGC,回收伊甸园区和幸存者区。
当幸存者区中的对象的age没有达到15也是可以晋升到老年代的。
总结:
- 针对S0,S1区的总结:复制之后,谁空谁是to.
- 关于与垃圾回收:频繁在新生区收集,很少在养老区收集,几乎不再永久区(元空间)收集。
对象分配的特殊情况
上面的概述是说的一般情况,下面说特殊情况:
以上过程前提是:不允许自动调整虚拟机内存空间。
放大招:代码举例与JVisualVM演示对象分配过程
package YoungOldArea;
import java.util.ArrayList;
import java.util.Random;
public class HeapInstanceTest {
byte[] buffer = new byte[new Random().nextInt(1024*200)];
public static void main(String[] args) {
ArrayList<HeapInstanceTest> list = new ArrayList<HeapInstanceTest>();
while (true){
list.add(new HeapInstanceTest());
try{
Thread.sleep(10);
}catch (InterruptedException e){
e.printStackTrace();
}
}
}
}
动图演示:
总结内存分配策略
如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能够被Survivor容纳的话,将被移动到Survivor空间中,并将对象年龄设置为1,对象在Survivor区中每熬过一次MinorGC,年龄就会增加1岁,当它的年龄增加到一定程度后(默认15岁,其实每个JVM,每个GC都有所不同)时,就会被晋升到老年代中。
对象晋升老年代的年龄阈值,可以通过选项-XX:MaxTenuringThreshold来进行设置。
针对不同年龄段对象分配原则如下所示:
- 优先分配到Eden
- 大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态独享年龄判断
- 如果Survivor区中相同年龄的对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代,无须等待MaxTenuringThreshold中要求的年龄
- 空间分配担保
- -XX:HandlePromotionFailure
通过逃逸分析看堆空间的分配策略
堆是分配对象的唯一选择吗?----不是
在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述:
- 随着JIT编译期的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化,所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
- 在Java虚拟机中,对象是在Java堆中分配内存的,这是一个普遍的常识。但是,有一种特殊情况,那就是如果经过逃逸分析(Escape Analysis)后发现,一个对象并没有逃逸出方法的话,那么就可能被优化成栈上分配。这样就无需在堆上分配内存,也无须进行垃圾回收了。这也是最常见的堆外存储技术。
- 此外,前面提到的基于openJDK深度定制的TaoBaoVM,其中创新的GCIH (GCinvisible heap) 技术实现off -heap,将生命周期较长的Java对象从heap中移至heap外,并且Gc不能管理GCIH内部的Java对象,以此达到降低Gc的回收频率和提升GC的回收效率的目的。
如何将堆上的对象分配到栈,需要使用逃逸分析手段。
- 这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
- 通过逃逸分析,Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
- 逃逸分析的基本行为就是分析对象动态作用域:
- 当一个对象在方法中被定义后,对象只在方法内部使用,则认为没有发生逃逸。
- 当一个对象在方法中被定义后,它被外部方法所引用,则认为发生逃逸。例如作为调用参数传递到其他地方中。
public class HeapTest {
public void myMethod(){
V v = new V();
//对象在方法内被使用,在方法内部销毁,最后没有指针指向它了,就说明 没有发生逃逸
v = null;
}
}
再举一个 会发生逃逸的例子:
public class Escape {
public static StringBuffer creatStringBuffer(String s1,String s2){
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
//返回sb对象,其他方法会调用这个方法使用这个sb对象,则会发生逃逸
return sb;
}
}
可以修改为:
public class Escape {
public static String creatStringBuffer(String s1,String s2){
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
}
逃逸分析的几种情况
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 e = new EscapeAnalysis();
}
//引用成员变量的值,发生逃逸
public void useEscapeAnalysis1(){
EscapeAnalysis e = getInstance();
}
}
如何快速的判断是否发生了逃逸分析,大家就看new的对象实体是否有可能在方法外被调用,如果有可能在方法外 被调用,则就是发生了逃逸。
有关逃逸的参数设置
在JDK 6u23版本之后,HotSpot中默认就已经开启了逃逸分析。如果使用的是较早的版本,开发人员可以通过
- -XX:+DoEscapeAnalysis 显示开启逃逸分析
- -XX:+PrintEscapeAnalysis 查看逃逸分析的筛选结果。
如果Eden区过大或者过小会怎样
- 如果Eden区多大,会使MinorGC没有意义,分代没有意义。
- 如果Eden区过小,会使YGC频率过高,使STW时间过多。降低了用户线程执行比例。
在发生MinorGC之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
- 如果大于,则此次MinorGC是安全的
- 如果小于,则虚拟机就会查看-XX:HandlePromootionFailure设置值是否允许担保失败
- 如果HandlePromootionFailure=true,那么会继续检查老年代最大可用连续空间是否大于晋升到老年代的对象的平均大小
- 如果大于,则尝试进行一次MinorGC,但这次MinorGC依然是有风险的。
- 如果小于,则改为进行一次FullGC
- 如果HandlePromotionFailure=false,则改为进行一次FullGC
在JDK6 Update24之后,HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略,观察OpenJDK中的源码变化,虽然源码中还定义了HandlePromotionFailure参数,但是在代码中已经不会再使用它了,JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行MinorGC,否则进行FullGC。
MinorGC、MajorGC、FullGC对比
三种GC简介
Jvm在进行GC时,并非每次都对上面三个内存(新生代、老年代:方法区)区域一起回收的,大部分时候回收的都是指新生代。
针对HotSpot VM的实现,它里面的GC按照回收区域又划分为两大种类型:一种是部分收集(Partial GC),一种是整堆收集(Full GC)
- 部分收集:不是完整收集整个Java堆的垃圾收集,其中又分为:
- 新生代收集(Minor GC / Young GC):只是新生代(Eden\S0,S1)的垃圾收集
- 老年代收集(Major GC / Old GC):只是老年代的垃圾收集
- 目前只有CMS GC会有单独的收集老年代的行为
- 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集
- 目前只有G1 GC会有这样的行为
- 整堆收集(Full GC):整个Java堆和方法区的垃圾收集
GC也是用线程来实现的,当垃圾回收时,STW,会影响到用户线程,所以调优就需要减少的GC。
最简单的分代式GC策略触发条件
年轻代GC(Minor GC)触发机制
- 当年轻带空间不足时,就会触发Minor GC,这里的年轻代指的是Eden区满,Survivor区满不会引发GC。(每次Minor GC 会清理Eden区的内存)
- 因为Java对象大都具备朝生熄夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快。这一定义激情戏又易于立即。
- Minor GC会引发STW,暂停其他用户的线程,等垃圾回收结束,用户线程才恢复运行。
老年代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了。
Full GC 触发机制
触发Full GC执行的情况有以下5种:
- 调用System.gc时,系统建议执行Full GC,但是不必然执行。
- 老年代空间不足
- 方法区空间不足
- 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
- 由Eden区、S0区向S1区复制时,对象大小大于S1区可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象的大小。
说明:Full GC 是开发或调优中尽量避免你的,这样暂停时间会短一些
GC举例与日志分析
package parameter;
import java.util.ArrayList;
import java.util.List;
public class GCTest {
public static void main(String[] args) {
int i =0;
try {
List<String> list = new ArrayList<>();
String a = "sgjergear";
while (true){
list.add(a);
a = a + a ;
i++;
}
}catch (Throwable t){
t.printStackTrace();
System.out.println("遍历次数为:"+ i);
}
}
}
设置显示垃圾回收详情:
显示的内容:
体会堆空间的分代思想
为什么需要把Java堆分代?不分代就不能正常工作了吗?
经研究,不同对象的声明周期,70%-90%的对象是临时对象。
- 新生代:有Eden、两块大小相同的Survivor(又称为from/to , S1/S0)构成,to 总为空。
- 老年代:存放新生代中经历多次GC仍然存活的对象。
其实不分代完全可以,分代的唯一理由就是优化GC性能。如果没有分代,那所有的对象在一块,就如同把一个学校的人都关在一个教室里。GC的时候要找到哪些对象没用,这样就会对全堆的区域进行扫描。很多对象都是朝生夕死的,如果分代的话,把新创建的对象放到某个地方,当GC的时候先把这块存储“朝生夕死”的对象区域进行回收,这样就会腾出很大的空间,而且还节约时间。
堆空间为每个线程分配的TLAB
什么是TLAB
- 从内存模型而不是垃圾收集角度,对Eden区域继续进行划分,JVM为每个线程分配了一个私有缓存区域,它包含在Eden空间内。
- 多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全问题,同时还能提升内存分配的吞吐量,因此我们可以将这种内存分配方式称为快速分配策略。
- 据我所知,所有OpenJDK衍生出来的JVM都提供了TLAB的设计
为什么有TLAB(Thread Local Allocation Buffer)
- 堆是线程共享区域,任何线程都可以访问到堆区中的共享数据
- 由于对象实例的创建在JVM中非常频繁,因此在开发环境下从堆区划分内存空间是线程不安全的
- 为避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度。
对象分配过程:TLAB
- 尽管不是所有的对象都能在TLAB分配成功,但JVN确实是将TLAB作为内存分配的首选。
- 在程序中,开发人员你可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
- 默认情况下,TLAB空间的内存非常小,仅占有整个Eden空间的1%,当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占Eden空间的百分比大小。
- 一旦对象在TLAB空间分配内存失败时,JVM就会尝试通过使用加锁机制确保数据操作的原子性,从而直接砸Eden空间中分配内存。
堆空间的参数设置
记是永远记不住的,所以知道去哪里找就行了,我写了另外一篇博客分享给大家,可以直接复制粘贴哟:
堆空间的参数设置