JVM之垃圾收集和内存分配

程序计数器，虚拟机栈，本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作

我们只有在程序处于运行期间时才能知道会创建哪些对象，java堆和方法区的内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存

3.2.1引用计数算法（python）

         计数算法：给对象中添加一个引用计数器，每当有一个地方引用，计数器值就加1；当引用失效时，计数器值减1；任何时刻计数器为0的对象就是不可能再被使用的

但是主流的JVM没有选用计数算法来管理内存，最主要的原因是它很难解决对象之间相互循环引用的问题。

3.2.2可达性分析算法（java c#）

         通过一系列的称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），

当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用，它们会被判断为可回收的对象

         java中，可作为GC Roots的对象包括：

         1.虚拟机栈（栈帧中的本地变量表）中引用的对象

         2.方法区中类静态属性引用的对象

         3.方法区中常量引用的对象

         4.本地方法栈中JNI（即Native方法）引用的对象

3.2.3 再谈引用

         以上两种算法都与引用有关，在JDK1.2后，Java对引用的概念进行了扩充，将引用分为（引用强度依次减弱）

         强引用（Strong Reference） 指在程序代码中普遍存在的，类似"Object obj=new Object()"只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象

         软引用（Soft Reference 类实现）指一些还有用但并非必需的对象。在将要发生内存溢出异常之前，将这些对象列进回收范围中进行第二次回收。

         弱引用（Weak Reference 类实现）    比软引用更弱，只能生存到下一次垃圾收集发生之前

         虚引用（Phantom Reference 类） 设置虚引用的唯一目的是能在这个对象被收集器回收时收到一个系统通知

3.2.4生存还是死亡（一个对象的finalize（）方法最多只会被系统自动调用一次）（尽量避免使用）

         即使在可达性分析算法中不可达的对象，并非“非死不可”，这时候它们处于‘缓刑’，要真正宣告一个对象死亡，至少要经历两次标记过程。

如果在可达性分析后没有和GC ROOTs相连的引用链，就会被第一次标记并且进行一次筛选，筛选条件是是否有必要执行finalize（）方法。当对象没有覆盖finalize，或者finalize（）方法已经被虚拟机调用过，JVM将这两种视为“没有必要执行”

         如果对象被判断为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，

并且之后由JVM自动建立的、低优先级的Finalizer线程去执行（指触发这个方法）它。finalize（）方法是对象逃脱死亡命运的最后一次机会，之后GC将对F-Queue中的对象进行第二次小规模的标记，

如果对象不再finalize中重新与引用链上的任何一个对象建立关联，则真的被回收了

3.2.5 回收方法区（永久代）

         常规应用进行一次GC一般可以回收70%—95%，而永久代的GC效率远低于此

         永久代的GC主要回收两部分内容：废弃常量和无用的类。 

         无用的类必须同时满足以下三个条件：

1.该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。

2.加载该类的ClassLoader已经被回收

3.该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

         可以（非必然）对无用类进行回收

         HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:TraceClassLoading、-XX:TraceClassUnLoading查看类加载和卸载信息，其中-verbose：class和-XX：TraceClassLoading可以在Porudct版的虚拟机中使用，-XX：TraceClassUnLoading

         在大量使用反射，动态代理，CGLib等ByteCode框架，动态生成JSP以及OSGI这类频繁自定义ClassLoader的场景都需要JVM具备类卸载的功能，以保证永久代不会溢出

3.3 垃圾收集算法

3.3.1标记-清除算法(Mark-Sweep)

首先标记处所有需要回收的对象,在标记完成后统一回收所有被标记的对象,后续算法都是基于这种思路并对其不足进行改进

主要有两个不足

1. 效率问题,标记和清除两个过程的效率都不高.
2. 空间问题,标记清除之后会产生大量不连续的内存碎片

3.3.2复制算法(Copying)

它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块.当这一块内存用完了,就将还存活的对象复制到另外一块,然后gc掉,每次都对整个半区

进行内存回收,实现简单,运行高效.但是内存被缩小为原来的一半,代价有点高

新生代中的对象98%是”朝生夕死”,可以将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次只使用Eden和其中一块Survivor.

当回收时,将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor.然后GC

3.3.3 标记-整理算法(Mark-Compact)

在老年代中,对象存活率较高,使用复制算法效率会大大降低.所以老年代采用标记-整理算法,区别于标记-清除在后续直接对可回收对象进行清理,

而是所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存.(先排序整理,再清除)

3.3.4分代收集算法(主)Generational Collection

根据堆中对象存活周期的不同将内存划分为新生代和老年代

新生代选用复制算法.

老年代因为对象存活率高,采用标记-清理或者标记-整理来进行回收

3.4 HotSpot的算法实现

3.4.1枚举根节点

在可达性分析算法中,可作为GC Roots的节点主要在全局性的引用(例如常量或静态属性)与执行上下文(例如栈帧中的本地变量表)中

可达性分析对执行时间的敏感还体现在GC停顿上,因为这项分析工作必须在一个必须保证一致性的快照中进行

一致性是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用还在不停变化的情况.

目前JVM使用的都是准确式GC(即VM知道内存中某个位置的数据具体是什么类型(引用类型还是基本类型),这样才可以在GC时准确判断堆上的数据是否可能被使用)

在HotSpot的实现是使用一组称为OopMap的数据结构来达到这个目的的,在类加载完成的时候,HotSpot就把对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中,也会在特定的位置记录下栈和寄存器中哪些位置是引用,这样GC在扫描时就可以直接得知这些信息了

3.4.2安全点(Safepoint)(满足GC标记阶段是,让所有Java线程挂起,这样GC才可以安全地标记对象)

在OopMap的帮助下HotSpot可以快速完成GC ROOTS枚举.

实际上HotSpot并没有为每条指令都生成OopMap,只在特定的位置记录了这些信息,即程序执行时并非在所有地方都能停顿下来开始GC,只有到安全点才可以

安全点的设定是以”是否具有让程序长时间执行的特征”为标准,

“长时间执行”的特征是指令序列复用(方法调用,循环跳转,异常跳转),具有这些功能的指令才会产生Safepoint

对于Safepoint,另一个问题是GC发生时,如何让所有线程跑到最近的安全点上再停顿下来

主动式中断的思想是当GC需要中断线程的时候,不直接对线程操作,仅仅简单地设置一个标志,各个线程执行时主动去轮询这个标志,

发现中断标志为真时就自己中断挂起.轮询标志的位置和安全点时重合的,另外再加上创建对象需要分配内存的地方

3.4.3安全区域Safe Region

Safepoint机制保证了程序执行时,在不太长的时间内就会遇到可进入GC的Safepoint.但当程序不执行的时候(例如线程处于Sleep或者Blocked状态),这时候线程无法响应JVM的中断请求,这时候需要安全区域(Safe Region)

安全区域是指一段引用关系不会发生变化,在任何地方开始GC都是安全的代码片段

在线程要离开Safe Region的时候,JVM会去检查系统是否完成GC Roots的跟节点枚举,如果完成,线程就继续执行,否则它就必须等到收到可以安全离开Safe Region的信号为止

3.5 垃圾收集器

垃圾收集器是内存回收的具体实现

3.5.1 Serial收集器

特点:单线程收集器,它在进行垃圾收集时,必须暂停其他所有的工作线程

是运行在Client模式下的默认新生代收集器(简单而高效,对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销,可以获得最高的单线程收集效率)

3.5.2 ParNew收集器

ParNew是Serial收集器的多线程版本,其他都一样

在Server模式下的JVM中首选的新生代收集器(只有它能与CMS收集器配合工作)

3.5.3 Parallel Scavenge收集器(吞吐量优先)

目标是达到一个可控制的吞吐量(Throughput CPU用于运行用户代码的时间与CPU总消耗时间的比值)

高吞吐量可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务

-XX:GCTimeRatio(设置吞吐量大小)

-XX:MaxGCPauseMillis(控制最大垃圾收集停顿时间)

-XX:UseAdaptiveSizePolicy(开关参数,就不需要手工指定新生代的大小(-Xmn),Eden与Survivor区的比例(-XX:SurvivorRatio),晋升老年代对象年龄(-XX:PretenureSizeThreshold)等参数)自适应策略

在对手工优化存在困难时,使用Parallel Scavenge收集器的GC自适应调节策略(GC Ergonomics)不失为一个不错的选择

3.5.4 Serial Old收集器

Serial的老年代版本,标记-整理算法 在Client模式下的虚拟机使用

两个用途:JDK1.5之前与Parallel Scavenge配合使用

                   作为CMS收集器的后备预案,在并发收集发生Concurrent Mode Failure时使用

3.5.5Parallel Old 收集器

时Parallel Scavenge收集器的老年代版本(JDK 1.6之后开始提供)

在注重吞吐量以及CPU资源敏感的场合,可以优先考虑Parallel Scavenge + Parallel Old收集器

3.5.6CMS收集器(Concurrent Mark Sweep)

CMS收集器是一种以获取最短回收停顿时间为目标的收集器

Web应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验,CMS符合这种需求

CMS基于”标记-清除”算法实现

包括四个阶段

         初始标记 :标记GC Roots能直接关联的对象

         并发标记 :进行GC Roots Tracing

--------------------------------------仍然需要”Stop the World”

         重新标记 :为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录

         并发清除

特点:耗时最长的并发标记和并发清除过程 收集器线程都可以与用户线程一起工作,并发收集,低停顿,从总体上来说 CMS收集器的内存回收过程是与用户线程一起并发执行的.

3.5.7G1收集器(Garbage-First)

面向服务端应用的垃圾收集器.

特点

1. 并行与并发:充分利用多CPU,多核的硬件优势,来缩短STOP-THE-WORLD停顿的时间,在部分收集器需要停顿Java线程执行的GC动作.G1收集器仍然可以通过并发的方式让Java程序继续执行.
2. 分代收集
3. 空间整合:G1运行期间不会产生内存空间碎片,收集后能提供规整的可用内存
4. 可预测的停顿:相对于CMS的另一大优势,G1除了追求低停顿外,还能建议可预测的停顿时间模型,明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒

使用G1收集器时  ,java堆的内存布局有很大区别,它将Java堆划分为多个大小相等的独立区域(Region),虽然还保留新生代和老年代的概率,但不再物理隔离,而是一部分Region(不需要连续)的集合

 

 

3.5.8理解GC日志

最前面的数字是GC发生的时间,FULL GC(停顿类型)是发生了STOP-THE-WORLD的,方块内是GC内存区域大小的变化,方块外是Java堆容量的变化

最后secs是GC所占用的时间

3.5.9垃圾收集器参数总结

 

3.6 内存分配与回收策略

3.6.1对象优先在Eden分配

大多数情况下,对象在新生代Eden区中分配.当Eden区没有足够空间进行分配时,虚拟机将发起一次Minor GC(新生代GC)

-XX:PrintGCDetails 收集器日志参数,告诉虚拟机在发生垃圾收集行为时打印内存回收日志

Minor GC(新生代GC)和Full GC(老年代GC)

Minor:速度快,频繁 ,发生在新生代的垃圾收集动作

Major/full :发生在老年代的GC,经常会伴随至少一次Minor GC,速度慢10倍以上

3.6.2大对象直接进入老年代

大对象:大量连续内存空间的Java对象(很长的字符串以及数组)

尽量避免创建一群”朝生夕死”的”短命大对象”,容易导致内存还有不少空间就提前触发垃圾收集以获取足够的连续空间来”安置”它们

-XX:PretenureSizeThreshold 3M应该写为3145728 参数设置可以让大于这个设置值的对象直接在老年代分配,来避免在Eden区以及两个Survivor区之间发生大量的内存复制

3.6.3长期存活的对象将进入老年代

为了识别哪些对象在新生代,哪些对象放在老年代,为了做到这点,JVM给每个对象定义了一个对象年龄(Age)计数器.如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间,并且Age=1,对象每在Survivor区熬过一次Minor GC,年龄就增加1岁,当age达到一定程度(默认15岁) 晋升到老年代-XX:MaxTenuringThreshold设置

3.6.4动态对象年龄判定

如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须达到设置值

3.6.5空间分配担保(JDK6Update24之后HandlePromotionFailure无效)

在Minor GC之前,JVM会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果条件成立,那么MinorGC可以确保是安全的

不成立的话,JVM会查看HandlePromotionFailure设置值是否允许担保失败.如果允许,那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,大于的话,进行一次Minor GC.小于或者HandlePromotionFailure设置不允许冒险,改为进行一次Full GC