面试虐我千百遍,我待JVM如初恋
作用一:面试需要
不懂JVM可以写出优质的代码,也可以做出优秀的项目,那么为什么要学习JVM?因为面试官最喜欢问的就是关于JVM的东西
作用二:中高等程序员的必备技能
可以项目管理,以及性能优化
VM就是Virtual Machine,虚拟机,他是一款软件,用来执行一系列虚拟计算机指令.可以将虚拟机分为系统虚拟机和程序虚拟机.
我们耳熟能详的VMware就是系统虚拟机,提供可运行完整操作系统的软件平台.
程序虚拟机典型的代表就是java虚拟机,在java虚拟机中执行的指令我们成为java字节码指令.
java技术的核心就是java虚拟机,因为所有的java程序都运行在java虚拟机内部.
java虚拟就是二进制字节码的运行环境,负责装在字节码到其内部,解释/编译为对应平台的机器码指令执行,每一条java指令,java虚拟机都有详细定义.怎么处理,结果放哪都有定义
特点:
如今的JVM不仅可执行java字节码文件.其他的语言编译的字节码文件也可以在jvm上运行,是一个跨平台语言
JVM是运行在操作系统之上的,与硬件没有直接的交互.
简单示意图:
先将.java文件转换为.class文件,jvm将字节码文件---------类加载器-------->内存的运行时数据区(由于字节码不能直接交给操作系统执行)----------执行引擎---------->字节码转为底层系统指令----------->CPU(这个过程需要调用本地库接口)
运行时数据区中的是Heap模块
java编译器输入的指令流给予一种给予栈的指令集架构,另一种是基于寄存器的指令集架构
基于栈式架构的特点
基于寄存器式架构特点
javap -v class//将.class文件反编译为指令集
由于跨平台设计,java指令集都是根据栈设计,不同cpu架构不同,所以不能设计为基于寄存器的
优点:跨平台,指令集小,编译器容易实现
缺点:性能低,同样的操作需要更多的指令
类加载器子系统负责从文件系统加载.class文件,class文件有特定的文件标识(CA FE BA BE 开头)
ClassLoader负责class文件的加载,能否运行有执行引擎觉得.
加载的类信息放在方法区中,还可以存放运行时常量池信息,还可以包含字符串字面量和数字常量
类什么时候初始化
类的初始化顺序
父类 static –> 子类 static –> 父类构造方法- -> 子类构造方法
结论:
子类的静态变量和静态初始化块的初始化是在父类的变量、初始化块和构造器初始化之前就完成了;
静态变量、静态初始化块顺序取决于它们在类中出现的先后顺序
变量、初始化块初始化顺序取决于它们在类中出现的先后顺序
JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器
JVM对class文件采用的是按需加载的方式,即需要改类时才会将class文件加载到内存中生成class对象,加载某个类的class文件,采用双亲委派模式,将请求交给父类处理
工作原理:
收到类加载请求,不会先加载,会将委托一层一层向上委托,直到没有父类加载器,若父类加载器完成任务就成功返回,若父类没有完成,又会返回给子类,若全部加载失败,抛出ClassNotFoundException异常
双亲委派优点:
作用:防止恶意代码污染java源代码
例如:我们定义类为String的包也命名为java.lang,因为这个类属于jdk,若没有沙箱安全机制,该类就会污染系统中的String.
因为沙箱安全机制,就委托顶层的类加载器查找这个类,没有就委托扩展类加载器,还没有就委托系统类加载器.由于STring就是jdk源代码,所以引导加载器就加载到了,找到后使用,后面的一概不使用,保证了恶意代码污染
在jvm中如何判断两个对象是属于同一个类
引用类的静态常量,不会导致初始化,常量指已经知道字面量的常亮,需要经过计算得到的常量还会导致初始化
构造某个类的数组时不会导致类的初始化
Student[] student = new Student[10];
主动使用和被动使用的区别在于类是否会被初始化
java8虚拟机规范规定,java虚拟机所管理的内存将会包含以下几个运行时数据区域:
程序计数器是一块较小的内存空间,可以看做是当前线程所执行的字节码的行号指示器
描述的是java方法执行的内存模型,每个方法在执行的同时都会创建一个线帧用于存储局部变量表,操作数栈,单台连接,方法出口等信息,每个方法调用到执行完成的过程就是一个线帧在虚拟机栈中入栈出栈的过程
与虚拟机栈的作用是一样的,只不过虚拟机栈是服务java方法的,而本地方法栈是虚拟机调用Native方法服务的
java虚拟机中内存最大的一块,被所有线程共享,在虚拟机启动时创建,java堆唯一的目的就是存放对象实例.
用于存储被虚拟机加载的类信息,常量,静态变量,即时变异后的代码等.
内存区域是硬盘和CPU的中间桥梁,承载着操作系统和应用程序的实时运行.
JVM内存布局规定了Java在运行过程中内存申请,分配,管理策略,保证JVM的高效稳定.
不同的JVM对内存的划分方式和管理机制存在着部分差异,以HotSpot虚拟机为例
红色代表线程共享,灰色代表单线程私有
**线程间共享:**堆,对外内存
**线程独立:**程序计数器,栈,本地方法栈
JVM中的程序计数寄存器中的Register命名来源于CPU寄存器,寄存器存储指令相关的现场信息,CPU只有把数据装在到寄存器才能运行.
程序计数器用来存储下一条指令的地址,由执行引擎读取下一条指令
使用程序计数器存储字节码指令地址有什么用?为什么使用程序计数器记录当前线程的执行地址呢?
因为CPU不停的切换各个线程,在切换回来时候,需要知道从哪个位置继续向下执行.
JVM的字节码解释器就需要通过改变程序计数器的值来明确下一条应该执行什么样的字节码指令
程序计数器为什么被设定为线程私有的
所谓的多线程 其实是在一段特定的时间执行其中一个线程,因为执行的时间段,PCU切换快,所以在用户看来就是多线程,在切换过程中必然导致中断或恢复,如何保障呢个分毫不差?
为了精确记录正在执行的字节码指令地址,最好的办法是为每一个线程分配一个程序计数器,这样每个线程都可以独立计算,互不干扰
由于跨平台的设计,java的指令根据栈设计,不同平台CPU架构不同,所以设计为基于栈的指令设计
优点:跨平台,指令集小,编译器易实现
缺点:性能下降,同样的功能需要的指令集多
**栈:**运行时单位,解决程序的运行问题
**堆:**存储的单位,解决数据存储的问题
Java Virtual Machine Stack,也叫java栈,每个线程在创建时都会创建一个虚拟机栈,内部保存一个个的栈帧,对应一次方法的调用
Java虚拟机栈是线程私有的,生命周期和线程一样
主观Java程序的运行,保存局部变量(8中基本数据类型,对象的引用地址),部分结果,参与方法的调用和返回
每个线程都有自己的栈,栈的数据都以栈帧为单位存储
在这个线程正在执行的每一个方法都对应一个栈帧
栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息
在一个栈中不可能引用另一个线程的栈帧(方法)
局部变量表(Local Variables)
局部变量表十一组变量存储空间,存放方法参数和方法内部定义的局部变量.对于基本数据类型的变量,直接存储他的值,对于引用类型的变量,则存的是指向对象的引用
操作数栈(Operand Stack)或表达式栈
栈最典型的一个应用就是用来对表达式求值,一个线程执行方法的过程就是不断执行语句的过程,归根到底是进行计算的过程.程序中所有计算过程都是借助操作数栈来完成的
动态链接(Dynamic Linking)
在方法执行的过程中有可能需要用到类中的常量,所以必须有一个引用指向运行时常量
方法返回地址(Return Address)
当一个方法执行完毕后,要返回调用它的地方,因此在栈帧中必须保存一个方法返回地址
什么情况会出现栈溢出?
方法执行时创建的栈帧超过了栈的深度,最优可能的就是方法递归调用产生这种结果
通过调整栈大小,就可以保证不出现溢出吗?
不能
并不会,只能延缓这种现象的出现,可能会影响其他内存空间
不会
java虚拟机栈管理java方法的调用,本地方法栈用于管理本地方法的调用
本地方法栈线程私有
允许被实现成固定或者可动态扩展的内存大小,内存溢出方面也是相同的
若线程申请分配的栈容量超过本地方法栈允许的最大容量抛出StackOverflowError
若本地方法可以动态扩展,在扩展时无法申请到足够的内存抛出OutOfMemoryError
本地方法栈使用c语言编写
具体实现是在Native Method Stack中登记native方法,在Execution Engine执行时加载本地方法库
一个JVM实例只存在一个堆内存,堆也是java内存管理的核心区域
java堆区在JVM启动时被创建,其空间大小也就被确定,是JVM管理的最大一块内存空间
堆内存大小可以调节
-Xms10m(堆起始大小) -Xmx30m(堆最大内存大小)
对在物理上是不连续的,在逻辑上应该被视为连续
所有的线程共享java堆,在这还可以划分线程私有的缓冲区
所有的对象实例都应在运行时分配在堆上
方法结束后,堆中的对象不会马上移除,仅仅垃圾收集的时候才会被移除
堆,是GC执行垃圾回收的重点区域
Java8之后堆内存分为:新生区(新生代)+老年区(老年代)
新生区被分为Eden(伊甸园)区和Survivor(幸存者)区
将对象根据存活概率分类,时间长的对象,放在固定区,减少扫描垃圾的时间及GC频率.针对不同的地区使用不同的回收算法,对算法扬长避短
为新对象分配内存是一件非常严谨和复杂的任务,不仅需要考虑内存如何分配,在哪分配等问题,由于内存分配算法与内存回收算法密切相关,所以还需要考虑 GC 执行完内存回收后是否会在内存空间中产生内存碎片.
配置新生代与老年代在堆结构的占比
在 HotSpot 中,Eden 空间和另外两个 survivor 空间缺省所占的比例是 8 : 1 : 1,当然开发
人员可以通过选项**-XX:SurvivorRatio**调整这个空间比例。比如-XX:SurvivorRatio=8
新生区的对象默认生命周期超过 15 ,就会去养老区养老
JVM在进行GC时,大部分是对新生区回收.针对HotSpot VM的实现,其中的GC按照回收区域分为两大类型:一种是部分收集,一种是整堆收集
**部分收集:**不是收集整个java堆的垃圾收集
**整堆收集:**收集整个java堆和方法区的垃圾收集
整堆收集出现的情况:
System.gc();
老年区空间不足
方法区空间不足
为什么会有TLAB(Thread Local Allocation Buffer)
堆区是线程共享的区域,任何线程都可以访问到堆区中的共享数据
由于对象实例创建在JVM中十分频繁,在并发环境下从堆区划分内存空间是线程不安全的
为避免多个线程操作同一个地址,需要使用加锁等机制,进而影响分配速度
什么是TLAB
全名Thread Local Allocation Buffer,线程本地分配缓存区
JVM使用TLAB避免多线程冲突,再给对象分配内存时,每个线程会有TLAB,避免线程同步,提高对象分配的效率
TLAB空间非常小,缺省情况下只占Eden的1%,通过-XX:TLABWasteTargetPercent设置占比
官网地址:https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html -XX:+PrintFlagsInitial 查看所有参数的默认初始值
-XX:+PrintFlagsFinal 查看所有参数的最终值(修改后的值)
-Xms:初始堆空间内存(默认为物理内的 1/64)
-Xmx:最大堆空间内存(默认为物理内存的 1/4)
-Xmn:设置新生代的大小(初始值及最大值)
-XX:NewRatio:配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio:设置新生代中 Eden 和 S0/S1 空间比例
-XX:MaxTenuringTreshold:设置新生代垃圾的最大年龄
-XX:+PrintGCDetails 输出详细的 GC 处理日志
字符串常量池为什么调整位置?
JDK7将字符串常量池放在堆空间中.因为永久代的回收效率低,在Full GC时才会执行垃圾回收,而Full GC是老年代空间不足,永久代不足时才会触发,导致StringTable回收效率不高,在开发中有大量的字符串被创建,回收效率低,导致永久代内存不足.放在堆里,能及时回收内存
方法区,**是线程共享的内存区域.**主要存储加载的类字节码,class/method/field等元数据,static final常量,static 变量,即时编译器编译后的代码等数据.方法区包含一个特殊的区域"运行时常量池".
方法区看做一个独立于java堆的内存空间
方法区在JVM启动时创建,物理内存地址是不连续的
大小可以选择固定大小或者可扩展大小
若系统定义太多的类,导致方法区溢出,抛出异常java.lang.OutMenoryError:Metaspace
关闭 JVM 就会释放这个区域的内存.
方法区,栈,堆的交互关系
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YZmWi8If-1618750524026)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618385838169.png)]
方法区用于存储:被虚拟机加载的类型信息,常量,静态变量,即时编译器编译后的代码缓存,运行常量池
通过反编译字节码文件查看.
反编译字节码文件,并输出值文本文件中,便于查看。参数 -p 确保能查看private 权限类型的字段或方法
javap -v -p Demo.class > test.txt
方法区有垃圾收集行为,《Java虚拟机规范》提到对方法区的约束宽松,不要求虚拟机在方法区中实现垃圾收集
该区域的回收效果不好,在类型的卸载,条件苛刻,但是该区域的回收有时又是必须的
方法区的垃圾收集主要回收两部分内容:运行时常量池中废弃的常量和不再使用
的类型。
回收废弃常量与回收 Java 堆中的对象非常类似。(关于常量的回收比较简单,
重点是类的回收)
下面也称作类卸载
判定一个常量是否“废弃”还是相对简单,而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:
**一个Native Method就是一个java调用非java代码的接口,**一个native method 是这样一个java方法:底层由非java语言实现
关键字 native 可以与其他所有的 java 标识符连用,但是 abstract 除外。
注意区分概念:
解释器:当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方法执行,将每条字节码文件"翻译"成对应平台的本地机器指令执行
**JIT编译器:**就是虚拟机将源代码一次性直接编译成和本地及其平台相关的机器语言,但并不是马上执行
JVM 设计者们的初衷仅仅只是单纯地为了满足 Java 程序实现跨平台特性,因此避免采用静态编译的方式由高级语言直接生成本地机器指令,从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。
解释器真正意义上所承担的角色就是一个运行时“翻译者”,将字节码文件中的内容“翻译”为对应平台的本地机器指令执行,执行效率低。
JIT 编译器将字节码翻译成本地代码后,就可以做一个缓存操作,存储在方法区的 JIT 代码缓存中(执行效率更高了)。
是否需要启动 JIT 编译器将字节码直接编译为对应平台的本地机器指令,则需要根据代码被调用执行的频率而定。JIT 编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化,将其直接编译为对应平台的本地机器指令,以此提升 Java 程序的执行性能。一个被多次调用的方法,或者是一-个方法体内部循环次数较多的循环体都可以被称之为“热点代码”。
目前 HotSpot VM 所采用的热点探测方式是基于计数器的热点探测
JIT编译器执行效率高为什么还需要解释器?
垃圾是指在运行程序中没有任何指针指向的对象,这个对象就是需要被回收的垃圾.
如果不及时对内存中的垃圾进行清理,这些垃圾对象所占的内存空间会一直保留到应用程序结束。甚至可能导致内存溢出。
在早期的 C/C++时代,垃圾回收基本上是手工进行的。开发人员可以使用 new关键字进行内存申请,并使用 delete 关键字进行内存释放。
MibBridge *pBridge= new cmBaseGroupBridge();
//如果注册失败,使用 Delete 释放该对象所占内存区域
if(pBridge->Register(kDestroy)!=NO ERROR)
delete pBridge;
这种方式可以灵活控制内存释放的时间,但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收,那么就会产生内存泄漏,垃圾对象永远无法被清除,随着系统运行时间的不断增长,垃圾对象所耗内存可能持续上升,直到出现内存溢出并造成应用程序崩溃。
有了垃圾回收机制后,上述代码极有可能变成这样
MibBridge *pBridge=new cmBaseGroupBridge();
pBridge->Register(kDestroy);
优点:无序开发人员手动参与内存的分配与回收,降低内存泄漏和内存溢出的风险
将程序员从繁重的内存管理中释放出来,专注于业务开发
垃圾收集器对年轻代回收,对老年代回收,对全栈和方法区回收,对java堆重点回收
次数上讲:频繁收集Yong区,较少收集Old区,基本不收集元空间(方法区)
垃圾标记阶段:主要是为了判断对象是否存活
可达性分析算法:也可以称为根搜索算法、追踪性垃圾收集
可达性分析实现思路
所谓"GCRoots”根集合就是一组必须活跃的引用
GC Roots 可以是哪些元素
小技巧:
由于 Root 采用栈方式存放变量和指针,所以如果一个指针,它保存了堆内存里面的对象,但是自己又不存放在堆内存里面,那它就是一个 Root
finalize() 方法机制
对象销毁前的回调函数:finalize();
Java 语言提供了对象终止(finalization)机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
当垃圾回收器发现没有引用指向一个对象,即:垃圾回收此对象之前,总会先调用这个对象的 finalize()方法。
finalize() 方法允许在子类中被重写,用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作,比如关闭文件、套接字和数据库连接等
永远不要主动调用某个对象的 finalize()方法,应该交给垃圾回收机制调用。理
由包括下面三点:
由于 finalize()方法的存在,虚拟机中的对象一般处于三种可能的状态。
可触及的:从根节点开始,可以到达这个对象。
可复活的:对象的所有引用都被释放,但是对象有可能在 finalize()中复活。
不可触及的:对象的 finalize()被调用,并且没有复活,那么就会进入不可触及状态。不可触及的对象不可能被复活,因为 finalize()只会被调用一次。
具体过程
当成功区分出内存中存活对象和死亡对象后,GC 接下来的任务就是执行垃圾回收,释放掉无用对象所占用的内存空间,以便有足够的可用内存空间为新对象分配内存。目前在 JVM 中比较常见的三种垃圾收集算法是:
执行过程
当堆中的有效内存空间(available memory)被耗尽的时候,就会停止整个程序(也被称为 stop the world),然后进行两项工作,第一项则是标记,第二项则是清除
标记:Collector 从引用根节点开始遍历,标记所有被引用的对象。一般是在对象的 Header 中记录为可达对象。(注意:标记的是被引用的对象,也就是可达对象,并非标记的是即将被清除的垃圾对象)。
清除:Collector 对堆内存从头到尾进行线性的遍历,如果发现某个对象在其 Header 中没有标记为可达对象,则将其回收
标记-清除算法的优点:
非常基础和常见的垃圾收集算法容易理解
标记-清除算法的缺点:
标记清除算法的效率不算高
在进行 GC 的时候,需要停止整个应用程序,用户体验较差
这种方式清理出来的空闲内存是不连续的,产生内碎片,需要维护一个空闲列表。(空闲列表-记录垃圾对象地址)。
注意:何为清除?
这里所谓的清除并不是真的置空,而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时,判断垃圾的位置空间是否够,如果够,就存放(也就是覆盖原有的地址)
为了解决标记-清除算法在垃圾收集效率方面的缺陷,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中,之后清除正在使用的内存块中的所有对象,交换两个内存的角色,最后完成垃圾回收
优点
没有标记和清除过程,实现简单,运行高效
复制过去以后保证空间的连续性,不会出现“碎片”问题。
缺点
此算法的缺点也是很明显的,就是需要两倍的内存空间。
对于 G1 这种分拆成为大量 region 的 GC,复制而不是移动,意味着 GC 需要维护 region 之间对象引用关系,不管是内存占用或者时间开销也不小
主要使用这种收集算法回收新生代
标记压缩算法执行过程
第一阶段和标记清除算法一样,从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端,按顺序排放。之后,清理边界外所有的空间
标记-压缩算法与标记-清除算法的比较
标记-压缩算法的最终效果等同于标记-清除算法执行完成后,再进行一次内存碎片整理,因此,也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法。
二者的本质差异在于标记-清除算法是一种非移动式的回收算法(空闲列表记录位置),标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
优点
消除了标记-清除算法当中,内存区域分散的缺点,我们需要给新对象分配内存时,JVM 只需要持有一个内存的起始地址即可。
消除了复制算法当中,内存减半的高额代价。
缺点
从效率上来说,标记-整理算法要低于复制算法。
移动对象的同时,如果对象被其他对象引用,则还需要调整引用的地址
移动过程中,需要全程暂停用户应用程序。即:STW
效率上复制算法最快,但是浪费太多内存
标记-整理算法相对来说更平滑一些,但是效率上不尽如人意,它比复制算法多了一个标记的阶段,比标记-清除多了一个整理内存的阶段。
为什么要使用分代收集算法
分代收集算法,是基于这样一个事实:不同的对象的生命周期是不一样的。因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率。一般是把Java 堆分为新生代和老年代,这样就可以根据各个年代的特点使用不同的回收算法,以提高垃圾回收的效率
年轻代(Young Gen)
年轻代特点:区域相对老年代较小,对象生命周期短、存活率低,回收频繁。
这种情况复制算法的回收整理,速度是最快的。复制算法的效率只和当前存活对象大小有关,因此很适用于年轻代的回收。而复制算法内存利用率不高的问题,通过 hotspot 中的两个 survivor 的设计得到缓解
老年代(Tenured Gen)
老年代特点:区域较大,对象生命周期长、存活率高,回收不及年轻代频繁。
这种情况存在大量存活率高的对象,复制算法明显变得不合适。一般是由标记- 清除或者是标记-清除与标记-整理的混合实现。
1.Mark 阶段的开销与存活对象的数量成正比。
2.Sweep 阶段的开销与所管理区域的大小成正相关。
3.Compact 阶段的开销与存活对象的数据成正比。
以 HotSpot 中的 CMS 回收器为例,CMS 是基于 Mark-Sweep 实现的,对于对象的回收效率很高。对于碎片问题,CMS 采用基于 Mark-Compact 算法的Serial Old 回收器作为补偿措施:当内存回收不佳(碎片导致的 ConcurrentMode Failure 时),将采用 Serial Old 执行 Full GC 以达到对老年代内存的整理。
增量收集算法
上述现有的算法,在垃圾回收过程中,应用软件将处于一种 Stop the World 的状态。在 Stop the World 状态下,应用程序所有的线程都会挂起,暂停一切正常的工作,等待垃圾回收的完成。如果垃圾回收时间过长,应用程序会被挂起很久,将严重影响用户体验或者系统的稳定性。为了解决这个问题,即对实时垃圾收集算法的研究直接导致了增量收集(Incremental Collecting)算法的诞生。
增量收集算法基本思想
如果一次性将所有的垃圾进行处理,需要造成系统长时间的停顿,那么就可以让垃圾收集线程和应用程序线程交替执行。每次,垃圾收集线程只收集一小片区域的内存空间,接着切换到应用程序线程。依次反复,直到垃圾收集完成。总的来说,增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理,允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
增量收集算法的缺点
虽然减少系统的停顿时间。但是,因为线程切换和上下文转换的消耗,会使得垃圾回收的总体成本上升,造成系统吞吐量的下降。
分区算法
一般来说,在相同条件下,堆空间越大,一次 GC 时所需要的时间就越长,有关GC 产生的停顿也越长。为了更好地控制 GC 产生的停顿时间,将一块大的内存区域分割成多个小块,根据目标的停顿时间,每次合理地回收若干个小区间,而不是整个堆空间,从而减少一次 GC 所产生的停顿。
分代算法将按照对象的生命周期长短划分成两个部分,分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用,独立回收。这种算法的好处是可以控制一次回收多少个小区间。
在默认情况下,通过 System.gc()者 Runtime.getRuntime().gc() 的调用,会显式触发 Full GC,同时对老年代和新生代进行回收,尝试释放被丢弃对象占用的内存。
JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况下,垃圾回收应该是自动进行的,无须手动触发,否则就太过于麻烦了。在一些特殊情况下,如我们正在编写一个性能基准,我们可以在运行之间调用System.gc()。
内存溢出
由于 GC 一直在发展,所有一般情况下,除非应用程序占用的内存增长速度非常快,造成垃圾回收已经跟不上内存消耗的速度,否则不太容易出现 OOM 的情况。
大多数情况下,GC 会进行各种年龄段的垃圾回收,实在不行了就放大招,来一次独占式的 Full GC 操作,这时候会回收大量的内存,供应用程序继续使用。Javadoc 中对 OutofMemoryError 的解释是,没有空闲内存,并且垃圾收集器也无法提供更多内存
内存泄漏
内存泄漏也称作“存储渗漏”。严格来说,只有对象不会再被程序用到了,但是 GC 又不能回收他们的情况,才叫内存泄漏。
尽管内存泄漏并不会立刻引起程序崩溃,但是一旦发生内存泄漏,程序中的可用内存就会被逐步蚕食,直至耗尽所有内存,最终出现 OutofMemory 异常,导致程序崩溃。
一些提供 close()的资源未关闭导致内存泄漏
数据库连接 dataSourse.getConnection(),网络连接 socket 和 io 连接必须手动 close,否则是不能被回收的。
Stop-the-World,简称 STW,指的是 GC 事件发生过程中,会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停,没有任何响应,有点像卡死的感觉,这个停顿称为 STW。
可达性分析算法中枚举根节点(GC Roots)会导致所有 Java 执行线程停顿,为什么需要停顿所有 Java 执行线程呢?
STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下,把用户正
常的工作线程全部停掉。
当内存空间还足够时,则能保留在内存中;如果内存空间在进行垃圾收集后还是很紧张,则可以抛弃这些对象
强引用(StrongReference):最传统的“引用”的定义,是指在程序代码之中普遍存在的引用赋值,即类似“object obj=new Object()”这种引用关系。无论任何情况下,只要强引用关系还存在,垃圾收集器就永远不会回收掉被引用的对象。宁可报 OOM,也不会 GC 强引用
软引用(SoftReference):在系统将要发生内存溢出之前,将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存,才会抛出内存溢出异常。
弱引用(WeakReference):被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时,无论内存空间是否足够,都会回收掉被弱引用关联的对象。
虚引用(PhantomReference):一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
当在 Java 语言中使用 new 操作符创建一个新的对象,并将其赋值给一个变量的
时候,这个变量就成为指向该对象的一个强引用。
只要强引用的对象是可触及的,垃圾收集器就永远不会回收掉被引用的对象。
只要强引用的对象是可达的,jvm 宁可报 OOM,也不会回收强引用
对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null,就是可以当做垃圾被收集了
强引用是造成 Java 内存泄漏的主要原因之一
**软引用是用来描述一些还有用,但非必需的对象。**只被软引用关联着的对象,在系统将要发生内存溢出异常前,会把这些对象列进回收范围之中进行第二次回收,如果这次回收还没有足够的内存,才会抛出内存溢出异常。注意,这里的第一次回收是不可达的对象
软引用通常用来实现内存敏感的缓存。比如:高速缓存就有用到软引用。如果还有空闲内存,就可以暂时保留缓存,当内存不足时清理掉,这样就保证了使用缓存的同时,不会耗尽内存
Object obj = new Object();// 声明强引用
SoftReference<Object> sf = new SoftReference<>(obj);
obj = null; //销毁强引用
弱引用也是用来描述那些非必需对象,只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统 GC 时,只要发现弱引用,不管系统堆空间使用是否充足,都会回收掉只被弱引用关联的对象。
// 声明强引用
Object obj = new Object();
WeakReference<Object> sf = new WeakReference<>(obj);
obj = null; //销毁强引用
弱引用对象与软引用对象的最大不同就在于,当 GC 在进行回收时,需要通过算法检查是否回收软引用对象,而对于弱引用对象,GC 总是进行回收。弱引用对象更容易、更快被 GC 回收
也称为“幽灵引用”或者“幻影引用”,是所有引用类型中最弱的一个
一个对象是否有虚引用的存在,完全不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它和没有引用几乎是一样的,随时都可能被垃圾回收器回收。它不能单独使用,也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时,总是 null 。
虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象后,将这个虚引用加入引用队列,以通知应用程序对象的回收情况。
// 声明强引用
Object obj = new Object();
// 声明引用队列
ReferenceQueue phantomQueue = new ReferenceQueue();
// 声明虚引用(还需要传入引用队列)
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
obj = null;
垃圾收集器没有在规范中进行过多的规定,可以由不同的厂商、不同版本的JVM 来实现。
由于 JDK 的版本处于高速迭代过程中,因此 Java 发展至今已经衍生了众多的 GC 版本。
从不同角度分析垃圾收集器,可以将 GC 分为不同的类型。
串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束。
和串行回收相反,并行收集可以运用多个 CPU 同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然与串行回收一样,采用独占式,使用"stop-the-world"机制。
按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。
并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间
独占式垃圾回收器(stop the world)一旦运行,就停止应用程序中的所有用户线程,直到垃圾回收过程完全结束。
按工作的内存区间分,又可分为年轻代垃圾回收器和老年代垃圾回收器。
吞吐量:运行用户代码的时间占总运行时间的比例(总运行时间:程序的运行时间+内存回收的时间)
垃圾收集开销:垃圾收集所用时间与总运行时间的比例。
暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间。
收集频率:相对于应用程序的执行,收集操作发生的频率。
内存占用:Java 堆区所占的内存大小。
快速:一个对象从诞生到被回收所经历的时间
串行回收器:Serial,Serial old
并行回收器:ParNew,Parallel scavenge,Parallel old
并发回收器:CMS、G1
新生代收集器:Serial,ParNew.Parallel scavenge;
老年代收集器:Serial old.Parallel old.cMS;
整堆收集器:G1;
只开启一条 GC 线程进行垃圾回收,并且在垃圾收集过程中停止一切用户线程(Stop The World)
一般客户端应用所需内存较小,不会创建太多对象,而且堆内存不大,因此垃圾收集器回收时间短,即使在这段时间停止一切用户线程,也不会感觉明显卡顿。因此 Serial 垃圾收集器适合客户端使用。
由于 Serial 收集器只使用一条 GC 线程,避免了线程切换的开销,从而简单高效
ParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。
ParNew 追求“低停顿时间”,与 Serial 唯一区别就是使用了多线程进行垃圾收集,在多 CPU 环境下性能比 Serial 会有一定程度的提升;但线程切换需要额外的开销,因此在单 CPU 环境中表现不如 Serial。
Parallel Scavenge 和 ParNew 一样,都是多线程、新生代垃圾收集器。但是两者有巨大的不同点:
Parallel Scavenge:追求 CPU 吞吐量,能够在较短时间内完成指定任务,因此适合没有交互的后台计算。
ParNew:追求降低用户停顿时间,适合交互式应用。
吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)
追求高吞吐量,可以通过减少 GC 执行实际工作的时间,然而,仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做,因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成,从而导致更高的暂停时间。而考虑到低暂停时间,最好频繁运行 GC 以便更快速完成,反过来又导致吞吐量下降。
Serial Old 收集器是 Serial 的老年代版本,都是单线程收集器,只启用一条 GC线程,都适合客户端应用。它们唯一的区别就是:Serial Old 工作在老年代,使用“标记-整理”算法;Serial 工作在新生代,使用“复制”算法。
Parallel Old 收集器是 Parallel Scavenge 的老年代版本,追求 CPU 吞吐量。
CMS:Concurrent Mark Sweep ,并发标记清除.
以获取最短回收停顿时间为目标的收集器,**在垃圾收集时是用户线程和GC线程并发执行,**所以在垃圾收集时用户并不会感到明显的卡顿
**初始标记:**Stop The World,仅使用一条初始标记线程对所有与GC ROOTS直接关联的对象进行标记
并发标记:使用多线标记线程,与用户线程并发执行.此过程可进行可达性分析,标记废弃对象
**重新标记:**Stop The World 使用多条标记线程并发执行,将并发标记过程新出现的废弃对象标记出来
**并发清除:**只是用一条GC线程,与用户线程并发执行,清除标记的对象,此过程非常耗时
并发标记与并发清除过程耗时最长,且可以与用户线程一起工作,因此,总体上说,CMS 收集器的内存回收过程是与用户线程一起并发执行的。
优点:
并发收集,低延迟
缺点:
为什么要发布Garbage First GC
原因就在于应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC 就不能保证应用程序正常进行,而经常造成 STW 的 GC 又跟不上实际的需求,所以才会不断地尝试对 GC 进行优化。G1(Garbage-First)垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一.
与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。
为什么叫做G1呢?
G1是一个并行回收器,将堆内存分割为不相关的区域,使用不同的Region来表示Eden,s0,s1区,老年区
G1跟踪各个Region里面的垃圾堆积的价值大小(回收获得空间大小和回收所需时间),在后台维护优先列表,每次根据循序的收集时间,优先回收价值最大的Region
由于侧重回收垃圾最大量的区间,所以叫垃圾优先
G1(Garbage-First)是一款面向服务端应用的垃圾收集器,主要针对配备多核 CPU 及大容量内存的机器,以极高概率满足 Gc 停顿时间的同时,还兼具高吞吐量的性能特征。
从整体上看,G1 是基于“标记-整理”算法实现的收集器,从局部(两个 Region之间)上看是基于“复制”算法实现的,这意味着运行期间不会产生内存空间碎片。
问题:一个对象和它内部所引用的对象可能不在同一个 Region 中,那么当垃圾回收
时,是否需要扫描整个堆内存才能完整地进行一次可达性分析
并不!
每个 Region 都有一个 Remembered Set,用于记录本区域中所有对象引用的对象所在的区域,进行可达性分析时,只要在 GC Roots 中再加上Remembered Set 即可防止对整个堆内存进行遍历。
如果不计算维护 Remembered Set 的操作,G1 收集器的工作过程分为以下几个步骤:
初始标记:Stop The World,仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
并发标记:使用一条标记线程与用户线程并发执行。此过程进行可达性分析,速度很慢。
最终标记:Stop The World,使用多条标记线程并发执行。
筛选回收:回收废弃对象,此时也要 Stop The World,并使用多条筛选回收线程并发执行。