JVM基本知识
JVM
一、JVM 体系结构概述
1.jvm简介
JVM是运行在操作系统上的,它与硬件没有直接交互。
JVM结构图概览
2.类加载器简介
类装载器 Class loader:
类装载器 Class loader 负责加载class文件,class文件在文件开头有特定的文件标示。
文件标识
将class文件字节码内容加载到内存中,并将这些内容转换成方法区中的运行时数据结构,ClassLoader只负责class文件的加载,至于它是否可以运行,则由Execution Engine决定 。
类加载是一个将class字节码文件实例化成Class对象并进行相关初始化的过程。全小写的class是关键字用来定义类,而首字母大写的Class它是所有class加载进内存的类。
记得我们在学习多线程8锁的时候,提到了锁普通方法是锁对象,锁静态方法是锁类,锁对象所得是实例化里面的car1,car2…,而锁类锁的则是Car Class,锁定地方不同,所以他们没有关联。
因此,创建一个对象的过程是,jvm把class文件加载进jvm的方法区里面,形成了Class模板,在通过Class模板创建实例对象。
虚拟机自带的加载器
- 启动类加载器(Bootstrap)C++
- 扩展类加载器(Extension)Java 第二层在JDK9版本中称为Platform ClassLoader即平台类加载器
JDK8及之前的加载器是Extension ClassLoader, - 应用程序类加载器(AppClassLoader)Java也叫系统类加载器,加载当前应用的classpath的所有类
- 用户自定义加载器 Java.lang.ClassLoader的子类,用户可以定制类的加载方式
虚拟机自带的加载器关系图
从这个图中,我们可以看到相关加载器的目录与继承关系,Bootstrap 是Extension的parent,Application 的parent是Extension,我们自己写的类的parent是Application,这些关系一定要记住,后面会用。
3.类加载器种类
启动类加载器(根加载器) - Bootstrap
我们提到了各种加载器,那么加载器在哪里能看到呢,我们拿Bootstrap举个例子,Bootstrap就是java\jdk1.8.0_111\jre\lib\下的rt.java。
Bootstrap会在java启动时加载最基本类,就像是地球没有太阳和水是不会存在生命的,Object类是所有类的父类,因此,我们可以知道,Object就是基础类,所以Object就会在java启动的时候被加载进内存中。
口说无凭,我们打开rt.java看一下里面到底有没有Object类。如图
也就是说,java在一开始的时候,根加载器就会将rt.jar加载进JVM中,保证java的最基本的运行,我们常见的String,ArrayList,等在rt.jar中。
扩展类加载器(Extension)
就像是我们无法预知未来会发生的事情一样,java同样也无法预知以后回有什么新特性,因此,java版本迭代增加很多拓展类,而Extension就是加载扩展类的加载器。扩展类的文件目录是,java\jdk1.8.0_111\jre\lib\ext,里面有很多拓展jar包,如图。
通过代码证明类与加载器的关系
我们前面了解到了,创建一个对象的过程是,jvm把class文件加载进jvm的方法区里面,形成了Class模板,在通过Class模板创建实例对象。那我们是不是也可以通过反射在通过对象查看自己的类模板是哪一个加载器加载进jvm的呢?如图:
代码很容易理解,那么运行结果呢?
我们发现运行结果是NULL,那么为什么是NULL呢。不要急,我们通过下一个例子来解释。如图
由上一段代码可知,Main类是我自己写的,那么他的加载器应该是AppClassLoader,而AppClassLoader的parent应该是ExtClassLoader,ExtClassLoader的parent应该是根加载器。我们来看一下验证结果。
我们发现ExtClassLoader的parent是NULL,由此证明,根加载器的表现形式就是NULL,那么为什么Bootstrap是NULL呢,因为根加载器是由C++语言写的,JAVA得不到,因此是NULL。
我们还发现,sun.misc.Launcher$这个东西,那么这个东西是什么呢,它其实是java虚拟机的入口,它的文件位置在rt.jar\sun\misc。也就是说java虚拟机最开始是从Launcher.class开始读,如图。
我们看一下在java启动的时候,根加载器到底加载了多少jar。如图
运行结果
得到的结论就是,java从一开始运行,就通过根加载器其为我们加载了这么多类进去。
4.类加载器的双亲委派机制
当一个类收到了类加载请求,他首先不会尝试自己去加载这个类,而是把这个请求委派给父类去完成,每一个层次类加载器都是如此,因此所有的加载请求都应该传送到启动类加载其中,只有当父类加载器反馈自己无法完成这个请求的时候(在它的加载路径下没有找到所需加载的Class),子类加载器才会尝试自己去加载。
采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object,不管是哪个加载器加载这个类,最终都是委托给顶层的启动类加载器进行加载,这样就保证了使用不同的类加载器最终得到的都是同样一个 Object对象。
众所周知,常用的String是在java.lang下的,如果我们自己建一个java.lang包,包里面建立一个String类,String类中的main方法打印输出"hello csdn",是否可以运行成功呢?
运行结果:
看到这个结果,不知道原理的人可能感觉到很委屈,学了这么长时间的java,最简单的输出打印都不对,而且还报了找不到main方法。
事实上,根据双亲委派模型,类加载器需要逐级向上加载,在parent中寻找是否有String类,终于在Bootstrap加载器中找到了java.lang.String,但是发现java.lang.String(系统自带)中并没有main方法,因此报错,这种安全机制也叫沙箱安全机制。
5.Native 方法
本地接口的作用是融合不同的编程语言为 Java 所用,它的初衷是融合 C/C++程序,Java 诞生的时候是 C/C++横行的时候,要想立足,必须有调用 C/C++程序,于是就在内存中专门开辟了一块区域处理标记为native的代码,它的具体做法是 Native Method Stack中登记 native方法,在Execution Engine 执行时加载native libraies。
目前该方法使用的越来越少了,除非是与硬件有关的应用,比如通过Java程序驱动打印机或者Java系统管理生产设备,在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达,比如可以使用 Socket通信,也可以使用Web Service等等,不多做介绍。
如下图所示,Thread类我们再熟悉不过了,使用Thread创建的线程中都有start方法,这个方法想必每个人都用过,就是使当前线程进入就绪状态,实际运行要看系统分配,我们深入Thread的start方法,我们发现,代码最初有一个,if(threadStatus!=0)
,如果满足这个条件,会抛出IllegalThreadStateException异常,如果我们在一个对象中调用了两次start(),就会触发这个异常,这章不是说线程,我们一笔带过。
在向下看,我们发现,started是一个Boolean值,start()实际上调用的是**start0();**调用完成之后,在把started=true 修改成true;
到这里可能会有人有疑问,native和start()有什么关系呢,我们继续看,我们查看start0()的源码,发现只有一行,如下图。
我们发现这是用 native 修饰的方法,说明调用的是操作系统底层C语言函数库的函数。
在JVM体系中,有一个本地方法栈(Native Method Stack),只要用native修饰的方法都放在本地方法栈中,当调用时,通过本地方法接口(Native Inteface)调用C语言的函数库,其他的事都交给C语言做,java不关心。
本地方法栈(Native Method Stack) 一笔带过
它的具体做法是Native Method Stack中登记native方法,在Execution Engine 执行时加载本地方法库。现在很少使用这种方式了,一般都是调服务。
6. PC寄存器
每个线程都有一个程序计数器,是线程私有的,就是一个指针,指向方法区中的方法字节码(用来存储指向下一条指令的地址,也即将要执行的指令代码),由执行引擎读取下一条指令,是一个非常小的内存空间,几乎可以忽略不记。
这块内存区域很小,它是当前线程所执行的字节码的行号指示器,字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。
讲人话,这个指针永远指向下一条要执行命令的地址,大学计算机组成原理学过。
7. 方法区
供各线程共享的运行时内存区域。它存储了每一个类的结构信息,例如运行时常量池(Runtime Constant Pool)、字段和方法数据、构造函数和普通方法的字节码内容。
上面讲的是规范,在不同虚拟机里头实现是不一样的,最典型的就是永久代(PermGen space)和元空间(Metaspace)(下面会说)。
But
实例变量存在堆内存中,和方法区无关
8. 栈(重点)
提到栈,必然会想到堆,这两个词经常联合出现,我们简单的说,在java中,Object object = new Object();
左边的是对象的引用,存放在栈,右边new出来的实例存放在堆。
栈主管运行,堆主管存储(后面会说),那么栈管运行体现在哪呢,运行时异常想必都很熟悉,如下图。
在打印运行时异常的语句中,就可以看到,e.printStackTrace();很明显,这时从Stack中打印运行时错误。
说了这么多,那么栈到底是什么呢?
栈也叫栈内存,主管Java程序的运行,是在线程创建时创建,它的生命期是跟随线程的生命期,线程结束栈内存也就释放,对于栈来说不存在垃圾回收问题,只要线程一结束该栈就Over,生命周期和线程一致,是线程私有的。线程主要存储8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。
栈是一个先进后出的数据结构,对于萌新自行去学习数据结构-栈,在java运行时,首先main()方法被压入栈,然后按照顺序执行依次压入其他方法,如果其他方法中依然嵌套方法,那么依旧顺序压入栈中,只有栈顶方法运行完之后才能执行调用它的方法,当然,如果被调用方法中有形参以及临时变量,也会顺带压入栈中,就像每颗子弹都有配套的火药一样。如果觉得抽象自己模拟下。
这也就是为什么当大家递归没写好的时候,程序会爆栈的原因了。
上面简略的说了栈存储了什么,我们在详细的整理下,栈到底存什么。
栈帧(见下一段)中主要保存3 类数据:
-
本地变量(Local Variables):输入参数和输出参数以及方法内的变量;
-
栈操作(Operand Stack):记录出栈、入栈的操作;
-
栈帧数据(Frame Data):包括类文件、方法等等。
栈运行原理:
栈中的数据都是以栈帧(Stack Frame)的格式存在,栈帧是一个内存区块,是一个数据集,是一个有关方法(Method)和运行期数据的数据集,当一个方法A被调用时就产生了一个栈帧 F1,并被压入到栈中,
A方法又调用了 B方法,于是产生栈帧 F2 也被压入栈,
B方法又调用了 C方法,于是产生栈帧 F3 也被压入栈,
……
执行完毕后,先弹出F3栈帧,再弹出F2栈帧,再弹出F1栈帧……
遵循先进后出,后进先出”原则。
栈帧图如下
每个方法执行的同时都会创建一个栈帧,用于存储局部变量表、操作数栈、动态链接、方法出口等信息,每一个方法从调用直至执行完毕的过程,就对应着一个栈帧在虚拟机中入栈到出栈的过程。栈的大小和具体JVM的实现有关,通常在256K~756K之间,与等于1Mb左右。
那么既然栈有大小限制,我们就模拟把栈填满,看看会发生什么,可能大家已经才出来了。
运行结果
果然,爆栈了,java.lang.StackOverFlowError,栈溢出了。
扩展
到这里,我们顺便提一下,StackOverFlowError是异常还是错误?
我们知道,异常和错误都有共同的父类Throwable。
在查文档,发现,StackOverFlowError是错误。
回到栈,举个例子
图示在一个栈中有两个栈帧:
栈帧 2是最先被调用的方法,先入栈,
然后方法 2 又调用了方法1,栈帧 1处于栈顶的位置,
栈帧 2 处于栈底,执行完毕后,依次弹出栈帧 1和栈帧 2,
线程结束,栈释放。
每执行一个方法都会产生一个栈帧,保存到栈(后进先出)的顶部,顶部栈就是当前的方法,该方法执行完毕后会自动将此栈帧出栈。
栈+堆+方法区的交互关系
-
HotSpot是使用指针的方式来访问对象:
HotSpot是java的一套规范。 -
Java堆中会存放访问类元数据的地址
元数据是方法区存储的类结构信息。 -
reference存储的就直接是对象的地址
基本类型和引用类型存在java栈中,引用类型(reference)存储的是指向对象实例的地址,而java堆中存储的是对象的实例数据和指向对象类型数据(元数据)的指针,方法区中存储的是对象类型数据(元数据)。他们的关系如上图所示。
二、堆体系结构概述(重点)
1. 堆简介
一个JVM实例只存在一个堆内存,堆内存的大小是可以调节的。类加载器读取了类文件后,需要把类、方法、常变量放到堆内存中,保存所有引用类型的真实信息,以方便执行器执行,堆内存分为三部分:
Heap堆(Java7之前)
堆内存逻辑上分为三部分:新生+养老+永久
2.对象生存入门篇
新生区(如下是首次讲述,简单版,先入门大致理解,下一小节详细)
新生区是类的诞生、成长、消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。
新生区又分为两部分: 伊甸区(Eden space)和幸存者区(Survivor pace) ,**所有的类都是在伊甸区被new出来的。**幸存区有两个: 0区(Survivor 0 space)和1区(Survivor 1 space)。当伊甸园的空间用完时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了,再对该区进行垃圾回收,然后移动到 1 区。那如果1 区也满了呢?再移动到养老区。若养老区也满了,那么这个时候将产生MajorGC(FullGC),进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存,就会产生OOM异常“OutOfMemoryError”。
如果出现java.lang.OutOfMemoryError: Java heap space异常,说明Java虚拟机的堆内存不够。
原因有二:
(1)Java虚拟机的堆内存设置不够,可以通过参数-Xms、-Xmx来调整(在开发中,一般为了防止内存抖动,我们把xm和xmx)。
(2)代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)。
3.对象生存提升篇
在基础篇的时候我们知道了,堆中分为新生代,老年代,永久代(java1.8元空间),其中新生代又分为伊甸区(Eden Space)、幸存0区(Survivor 0 Space)、幸存1区(Survivor 0 Space)。
在提升篇我们从GC的角度把堆细分一下。
在jvm中,为新生代分配(1/3)的堆空间,为老年代分配(2/3)空间,至于为什么这么分配,是为了避免MajorGC,因为MajorGC比MinorGC更加耗时,后面GC课程会详细介绍。
我们把曾经的Survivor区也由0区和1区详细划分成 Survivor Form区和Survicor To区。
所以Java堆从GC的角度还可以细分为:新生代(Eden区、From Survivor 区 和 To Survivor区)以及老年代。如下图所示
MinorGC的过程(复制->清空->互换) 详细过程如下:
-
1:eden;SurvivorFrom 复制到 SurvivorTo;年龄+1
首先,当Eden区满的时候会触发第一次GC,把还活着的对象拷贝到SurvivorFrom区,当Eden区再次触发GC的时候会扫描Eden区和From区域,对这两个区域进行垃圾回收,经过这次回收后还存活的对象,则直接复制到To区域(如果有对象的年龄已经达到了老年的标准,则赋值到老年代区),同时把这些对象的年龄+1 -
2:清空 eden、SurvivorFrom
然后,清空Eden和SurvivorFrom中的对象,也即复制之后有交换,谁空谁是to -
3:SurvivorTo和 SurvivorFrom 互换
最后,SurvivorTo和SurvivorFrom互换,原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代 -
4:大对象特殊情况
如果分配的新对象比较大Eden区放不下但Old区可以放下时,对象会被直接分配到Old区(即没有晋升这一过程,直接到老年代了)
流程图如图所示:
新生区为啥需要Survivor区?
不就是新生代到老年代么,直接Eden到Old不好了吗?为啥要这么复杂?想想如果没有Survivor区,Eden区每进行一次MinorGC存活的对象就会被送到老年代,老年代很快就会被填满。而有很多对象虽然一次MinorGC没有消灭但其实也并不会蹦跶多久,或许第2次第3次就需要被清除。这时候移入老年区,很明显不是一个明智的决定。所以Survivor的存在意义就是减少被送到老年代的对象,进而减少FullGC的发生。Survivor的预筛选保证只有经历16次MinorGC还能在新生代中存活的对象,才会被送到老年代。
新生区为啥需要两个Survivor区?
设置两个Survivor区最大的好处就是解决内存碎片化。
假设Survivor如果只有一个区域会怎样?MinorGC执行后Eden区被清空了,存活的对象放到了Survivor区,而之前Survivor区中的对象,可能也有一些是需要被清除的。问题来了,这时候我们怎么清除它们?在这种场景下,我们只能标记清除,而我们知道标记清除最大的问题就是内存碎片,在新生代这种经常会消亡的区域,采用标记清除必然会让内存产生严重的碎片化。因为Survivor有2个区域,所以每次MinorGC,会将之前Eden区和From区中的存活对象复制到To区域。第二次MinorGC时,From与To职责兑换,这时候会将Eden区和To区中的存活对象再复制到From区域,以此反复。这种机制最大的好处就是,整个过程中,永远有一个Survivorspace是空的,另一个非空的Survivorspace是无碎片的。那么,Survivor为什么不分更多块呢?比方说分成三个、四个、五个?显然,如果Survivor区再细分下去,每一块的空间就会比较小,容易导致Survivor区满,两块Survivor区是经过权衡之后的最佳方案。
4.方法区详解
java的方法区类似于接口,是一种规范,落地实现是永久代(java1.7)或者元空间(java1.8)
前面说过,真正占用堆内存的是新生代和老年代,而永久代或者元空间,实际上是逻辑上划分的一块,所以下图是用虚线标着的。
其实很多对象从新生到死亡只有很短暂的时间,而且在一次GC中能存活下来的也寥寥无几。
实际而言,方法区(Method Area)和堆一样,是各个线程共享的内存区域,它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码等等,虽然JVM规范将方法区描述为堆的一个逻辑部分,但它却还有一个别名叫做Non-Heap(非堆),目的就是要和堆分开。
对于HotSpot虚拟机,很多开发者习惯将方法区称之为“永久代(Parmanent Gen)” ,但严格本质上说两者不同,或者说使用永久代来实现方法区而已,永久代是方法区(相当于是一个接口interface)的一个实现.
永久区Perm(java7之前有)
永久存储区是一个常驻内存区域,用于存放JDK自身所携带的 Class,Interface 的元数据,也就是说它存储的是运行环境必须的类信息,被装载进此区域的数据是不会被垃圾回收器回收掉的,关闭 JVM 才会释放此区域所占用的内存。
元空间Metaspace (java8)
区别于永久代, 元空间在本地内存中分配。
在JDK8里,之前Perm区中的内容:
字符串常量移至堆内存;
其他内容包括类元信息、字段、静态属性、方法、常量等都移动至元空间内
三、堆参数调优入门
1. java7与java8的区别
java7
-Xms:堆内存初始大小
-Xmx:堆内存最大大小
-Xmn:新生代大小
在java1.7中,永久带使用的JVM的堆内存
-XX:permSize:永久代大小
-XX:MaxPermSize:永久代最大大小
java8
JDK 1.8之后将最初的永久代取消了,由元空间取代。
在Java8中,永久代已经被移除,被一个称为元空间的区域所取代。元空间的本质和永久代类似。
元空间与永久代之间最大的区别在于:
永久带使用的JVM的堆内存,但是java8以后的元空间并不在虚拟机中而是使用本机物理内存。
因此,默认情况下,元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中,这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。
2. 堆参数调优入门
Key | Value |
---|---|
-Xms | 设置初始分配大小,默认为物理内存的 “1/64” |
-Xmx | 最大分配内存,默认为物理内存的 “1/4” |
-XX:+PringGCDetails | 输出详细的GC处理日志 |
下面以16G内存设备为例,查看女尼吉的最大内存量和内存总量
public static void main(String[] args){
//返回 Java 虚拟机试图使用的最大内存量。
long maxMemory = Runtime.getRuntime().maxMemory() ;
//返回 Java 虚拟机中的内存总量。
long totalMemory = Runtime.getRuntime().totalMemory() ;
System.out.println("TOTAL_MEMORY(-Xms) =
" + totalMemory + "(字节)、" + (totalMemory / (double)1024 / 1024) + "MB");
System.out.println("MAX_MEMORY(-Xmx) =
" + maxMemory + "(字节)、" + (maxMemory / (double)1024 / 1024) + "MB");
}
运行结果:
发现默认的情况下分配的内存是总内存的“1 / 4”、而初始化的内存为“1 / 64”
在实际开发中,为了防止内存动态扩容造成的内存抖动,我们一般将-Xms和Xmx设置成一样的大小。
我们通过VM参数可以修改这些值。
如图所示,在IDEA的VM options设置的参数。现在把-Xms和-Xmx都设置成1024,并且打印GC日志。
运行结果:
还是上面测试的代码,可以发现,-Xms和-Xmx都修改成了981.5MB。
在打印的堆日志中可以看到
PSYoungGen+ParOldGen+Metaspace刚好等于981.5
eden占PsYoungGen的8/10,form和to占2/10
学到了这里,我们可以看一下VM在GC的时候经历的步骤。我们可以通过无限的创建相对大的对象,来撑满新生代和老年代,顺便触发OOM。
我们可以看到,每次新生代满了都会触发GC,每次老年代满了都会触发Full GC, 直到最后Full GC也清理不了之后,报OOM。
简单总结如图所示。
JVM布局如图所示。
四、GC
1. GC简介
GC是分代(新生代、老年代、永久代(原空间))收集算法,由于新生代会频繁的新生对象,所以需要频繁清理新生代,当GC之后,新生代的资源所剩无几,能进入到老年代的资源更是少之又少,再加之老年代采用Full GC,所以较少收集老年代, 和永久代一样,元空间存储的资源都很重要,基本不回收(不是绝对)。
也不是所有的区域都需要GC的,GC也是分区域回收的。
JVM在进行GC时,并非每次都对上面三个内存区域一起回收的,大部分时候回收的都是指新生代。
因此GC按照回收的区域又分了两种类型,一种是普通GC(minor GC),一种是全局GC(major GC or Full GC)
Minor GC和Full GC的区别
普通GC(minor GC):只针对新生代区域的GC,指发生在新生代的垃圾收集动作,因为大多数Java对象存活率都不高,所以Minor GC非常频繁,一般回收速度也比较快。
全局GC(major GC or Full GC):指发生在老年代的垃圾收集动作,出现了Major GC,经常会伴随至少一次的Minor GC(但并不是绝对的)。Major GC的速度一般要比Minor GC慢上10倍以上
前面提到,新生代与老年代的GC算法是不一样的,下面讲解GC四大算法。
2. GC算法之引用计数(不采用)
这个算法很简单,一个资源被引用+1,不被引用-1,被引用数量越多越难被清理。
循环引用指的是两个资源相互引用。
3. GC算法之复制算法(Copying)
年轻代中使用的是Minor GC,这种GC算法采用的是复制算法(Copying)
Minor GC会把Eden中的所有活的对象都移到Survivor区域中,如果Survivor区中放不下,那么剩下的活的对象就被移到Old generation中,也即一旦收集后,Eden是就变成空的了。
当对象在 Eden出生后,在经过一次 Minor GC 后,如果对象还存活,并且能够被另外一块 Survivor 区域所容纳( 上面已经假设为 from 区域,这里应为 to 区域,即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 ),则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中,然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 ),并且将这些对象的年龄设置为1,以后对象在 Survivor 区每熬过一次 Minor GC,就将对象的年龄 + 1,当对象的年龄达到某个值时 ( 默认是 15 岁,通过-XX:MaxTenuringThreshold 来设定参数),这些对象就会成为老年代。
-XX:MaxTenuringThreshold — 设置对象在新生代中存活的次数
HotSpot JVM把年轻代分为了三部分:1个Eden区和2个Survivor区(分别叫from和to)。默认比例为8:1:1,一般情况下,新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后,如果仍然存活,将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC,年龄就会增加1岁,当它的年龄增加到一定程度时,就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(90%以上),所以在年轻代的垃圾回收算法使用的是复制算法,复制算法的基本思想就是将内存分为两块,每次只用其中一块,当这一块内存用完,就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。
在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区域是空的。Minor GC会一直重复这样的过程,直到“To”区被填满,“To”区被填满之后,会将所有对象移动到年老代中。
因为Eden区对象一般存活率较低,一般的,使用两块10%的内存作为空闲和活动区间,而另外80%的内存,则是用来给新建对象分配内存的。一旦发生GC,将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间,接下来,将之前90%的内存全部释放,以此类推。
复制算法的优点很容易看出,就是没有内存碎片。
复制算法它的缺点也是相当明显的。
1、它浪费了一半的内存,这太要命了。
2、如果对象的存活率很高,我们可以极端一点,假设是100%存活,那么我们需要将所有对象都复制一遍,并将所有引用地址重置一遍。复制这一工作所花费的时间,在对象存活率达到一定程度时,将会变的不可忽视。 所以从以上描述不难看出,复制算法要想使用,最起码对象的存活率要非常低才行,而且最重要的是,我们必须要克服50%内存的浪费。
4. GC算法之标记清除(Mark-Sweep)
老年代一般是由标记清除或者是标记清除与标记整理的混合实现。
通俗的话解释一下标记清除算法,就是当程序运行期间,若可以使用的内存被耗尽的时候,GC线程就会被触发并将程序暂停,随后将要回收的对象标记一遍,最终统一回收这些对象,完成标记清理工作接下来便让应用程序恢复运行。
主要进行两项工作,第一项则是标记,第二项则是清除。
标记:从引用根节点开始标记遍历先标记出要回收的对象。
清除:遍历整个堆,把标记的对象清除。
缺点:此算法需要暂停整个应用,会产生内存碎片
做个总结
1、首先,它的缺点就是效率比较低(递归与全堆对象遍历),而且在进行GC的时候,需要停止应用程序,这会导致用户体验非常差劲
2、其次,主要的缺点则是这种方式清理出来的空闲内存是不连续的,这点不难理解,我们的死亡对象都是随即的出现在内存的各个角落的,现在把它们清除之后,内存的布局自然会乱七八糟。而为了应付这一点,JVM就不得不维持一个内存的空闲列表,这又是一种开销。而且在分配数组对象的时候,寻找连续的内存空间会不太好找。
怎么优化?
5. GC算法之标记压缩(Mark-Compact)
老年代一般是由标记清除或者是标记清除与标记整理的混合实现
在整理压缩阶段,不再对标记的对像做回收,而是通过所有存活对像都向一端移动,然后直接清除边界以外的内存。
可以看到,标记的存活对象将会被整理,按照内存地址依次排列,而未被标记的内存会被清理掉。如此一来,当我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可,这比维护一个空闲列表显然少了许多开销。
标记整理算法: 弥补标记清除算法当中内存区域分散的缺点,也消除了复制算法当中内存减半的高额代价。
标记/整理算法唯一的缺点就是效率也不高,不仅要标记所有存活对象,还要整理所有存活对象的引用地址。
从效率上来说,标记/整理算法要低于复制算法。
6. 总结
内存效率:复制算法>标记清除算法>标记整理算法(此处的效率只是简单的对比时间复杂度,实际情况不一定如此)。
内存整齐度:复制算法=标记整理算法>标记清除算法。
内存利用率:标记整理算法=标记清除算法>复制算法。
可以看出,效率上来说,复制算法是当之无愧的老大,但是却浪费了太多内存,而为了尽量兼顾上面所提到的三个指标,标记/整理算法相对来说更平滑一些,但效率上依然不尽如人意,它比复制算法多了一个标记的阶段,又比标记/清除多了一个整理内存的过程
难道就没有一种最优算法吗?
回答:无,没有最好的算法,只有最合适的算法。==========>分代收集算法。
**年轻代(Young Gen)
年轻代特点是区域相对老年代较小,对像存活率低。**
这种情况复制算法的回收整理,速度是最快的。复制算法的效率只和当前存活对像大小有关,因而很适用于年轻代的回收。而复制算法内存利用率不高的问题,通过hotspot中的两个survivor的设计得到缓解。
**老年代(Tenure Gen)
老年代的特点是区域较大,对像存活率高。**
这种情况,存在大量存活率高的对像,复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。
Mark阶段的开销与存活对像的数量成正比,这点上说来,对于老年代,标记清除或者标记整理有一些不符,但可以通过多核/线程利用,对并发、并行的形式提标记效率。
Sweep阶段的开销与所管理区域的大小形正相关,但Sweep“就地处决”的特点,回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法,仍然是效率最好的。但是需要解决内存碎片问题。
Compact阶段的开销与存活对像的数据成开比,如上一条所描述,对于大量对像的移动是很大开销的,做为老年代的第一选择并不合适。
基于上面的考虑,老年代一般是由标记清除或者是标记清除与标记整理的混合实现。
以hotspot中的CMS回收器为例,CMS是基于Mark-Sweep实现的,对于对像的回收效率很高,而对于碎片问题,CMS采用基于Mark-Compact算法的Serial Old回收器做为补偿措施:当内存回收不佳(碎片导致的Concurrent Mode Failure时),将采用Serial Old执行Full GC以达到对老年代内存的整理。
7. 小题
- JVM内存模型以及分区,需要详细到每个区放什么?
- 堆里面的分区:Eden,survival from to,老年代,各自的特点?
- GC的三种收集方法:标记清除、标记整理、复制算法的原理与特点,分别用在什么地方?
- Minor GC与Full GC分别在什么时候发生 ?