GC

JVM的内存管理结构

　　

JVM运行时数据区 ①程序计数器(Program Counter Register)   　　程序计数器是用于存储每个线程下一步将执行的JVM指令，如该方法为native的，则程序计数器中不存储任何信息   ②JVM栈(JVM Stack)   　　JVM栈是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址   ③堆(heap)   　　它是JVM用来存储对象实例以及数组值的区域，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收。   　　（1）堆是JVM中所有线程共享的，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的   　　（2）Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配   　　（3）TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。   ④方法区（Method Area）   　　（1）在Sun JDK中这块区域对应的为PermanetGeneration，又称为持久代。   　　（2）方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当开发人员在程序中通过Class对象中的getName、isInterface等方法来获取信息时，这些数据都来源于方法区域，同时方法区域也是全局共享的，在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。   ⑤本地方法栈（Native Method Stacks）   　　JVM采用本地方法栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。   ⑥运行时常量池（Runtime Constant Pool） 　　存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。JVM在加载类时会为每个class分配一个独立的常量池，但是运行时常量池中的字符串常量池是全局共享的。

GC的作用：

• 分配内存
• 确保被引用对象的内存不被错误的回收
• 回收不再被引用的对象

　  JVM将堆分成了二个大区新生代（Young）和老年代（Old），新生代又被进一步划分为Eden和Survivor区，而Survivor由FromSpace和ToSpace组成，也有些人喜欢用Survivor1和Survivor2来代替。这里为什么要将Young划分为Eden、Survivor1、Survivor2这三块，给出的解释是“Young中的98%的对象都是朝生夕死，所以将内存分为一块较大的Eden和两块较小的Survivor1、Survivor2，JVM默认分配是8:1:1，每次调用Eden和其中的Survivor1（FromSpace），当发生回收的时候，将Eden和Survivor1（FromSpace）存活的对象复制到Survivor2（ToSpace），然后直接清理掉Eden和Survivor1的空间。”

　　堆结构图如下：

　　

　　新生代：新创建的对象都是用新生代分配内存，Eden空间不足时，触发Minor GC，这时会把存活的对象转移进Survivor区。
　　老年代：老年代用于存放经过多次Minor GC之后依然存活的对象。

　　新生代的GC（Minor GC）：新生代通常存活时间较短基于Copying算法进行回收，所谓Copying算法就是扫描出存活的对象，并复制到一块新的完全未使用的空间中，对应于新生代，就是在Eden和FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发，指针保持最后一个分配的对象在新生代区间的位置，当有新的对象要分配内存时，用于检查空间是否足够，不够就触发GC。当连续分配对象时，对象会逐渐从Eden到Survivor，最后到老年代。

　　老年代的GC（Major GC/Full GC）：老年代与新生代不同，老年代对象存活的时间比较长、比较稳定，因此采用标记(Mark)算法来进行回收，所谓标记就是扫描出存活的对象，然后再进行回收未被标记的对象，回收后对用空出的空间要么进行合并、要么标记出来便于下次进行分配，总之目的就是要减少内存碎片带来的效率损耗。

垃圾收集算法：

　　①Mark-Sweep（标记-清除）算法

　　这是最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。具体过程如下图所示：

　　

　　从图中可以很容易看出标记-清除算法实现起来比较容易，但是有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。　

　　②.Copying（复制）算法

　　为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。具体过程如下图所示：

　　

　　这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。　很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。我们的新生代GC算法采用的是这种算法

　　③Mark-Compact（标记-整理）算法

　　为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。具体过程如下图所示：

　　

　　在一般厂商JVM中老年代GC就是使用的这种算法，由于老年代的特点是每次回收都只回收少量对象。

垃圾收集器

用户可以根据自己的需求组合出新年代和老年代使用的收集器

下面是常见的划分办法

　  新生代GC ：

• 串行GC(SerialGC)：在整个扫描和复制过程采用单线程的方式来进行，适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上，是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。
• 并行回收GC(ParallelScavenge)：在整个扫描和复制过程采用多线程的方式来进行，适用于多CPU、对暂停时间要求较短的应用上，是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。
• 并行GC(ParNew):与老年代的并发GC配合使用。

　  老年代GC：

• 串行GC(Serial MSC):client模式下的默认GC方式，可通过-XX:+UseSerialGC强制指定。每次进行全部回收，进行Compact，非常耗费时间。
• 并行GC(Parallel MSC):吞吐量大，但是GC的时候响应很慢：server模式下的默认GC方式，也可用-XX:+UseParallelGC=强制指定。可以在选项后加等号来制定并行的线程数。
• 并发GC(CMS):响应比并行gc快很多，但是牺牲了一定的吞吐量。

思考“GC是在什么时候，对什么东西，做了什么事情？”

• 什么时候  从字面上翻译过来就是什么时候触发我们的GC机制

　　①在程序空闲的时候。这个回答无力吐槽

　　②程序不可预知的时候/手动调用system.gc()。关于手动调用不推荐

　　③Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。

　　这时候如果你们讲出新生代和老年代的话或许会更细的了解一下Minor GC、Full GC、OOM什么时候触发！

　　创建对象是新生代的Eden空间调用Minor GC；当升到老年代的对象大于老年代剩余空间Full GC；GC与非GC时间耗时超过了GCTimeRatio的限制引发OOM。

• 什么东西   从字面的意思翻译过来就是能被GC回收的对象都有哪些特征

　　①超出作用域的对象/引用计数为空的对象。

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

　　②从GC Root开始搜索，且搜索不到的对象

　　跟搜索算法：以一系列名为 GC Root的对象作为起点，从这些节点开始往下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链的时候，则就证明此对象是不可用的。

　　这里会提出一个思考，什么样的对象能成为GC Root ： 虚拟机中的引用的对象、方法区中的类静态属性引用的对象、方法区中常量引用的对象、本地方法栈中jni的引用对象。

　　③从root搜索不到，而且经过第一次标记、清理后，仍然没有复活的对象。

• 做什么

　　不同年代、不同种类的收集器很多，不过总体的作用是删除不使用的对象，腾出内存空间。补充一些诸如停止其他线程执行、运行finalize等的说明。

上面什么时候容易发生内存泄露？

1. 静态集合类像HashMap、Vector等
2. 各种连接，数据库连接，网络连接，IO连接等没有显示调用close关闭，不被GC回收导致内存泄露。
3. 监听器的使用，在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露。
4. 变量不合理的作用域
5. 单例模式可能会造成内存泄漏

OOM（“Out of Memory”）异常一般主要有如下2种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace

这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。

例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。

2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace

通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize 调大（一般256m能满足绝大多数应用程序需求）。将部分Java类放到容器共享区（例如Tomcat share lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。

full GC触发的条件

除直接调用System.gc外，触发Full GC执行的情况有如下四种。

1. 旧生代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：java.lang.OutOfMemoryError: Java heap space

为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

2. Permanet Generation空间满

PermanetGeneration中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：java.lang.OutOfMemoryError: PermGen space

为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

3. CMS GC时出现promotion failed和concurrent mode failure

对于采用CMS进行旧生代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能会触发Full GC。

promotionfailed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代也放不下造成的；concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代，而此时旧生代空间不足造成的。

应对措施为：增大survivorspace、旧生代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况，可通过设置-XX:CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。

4. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间

这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。

例如程序第一次触发MinorGC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，则执行Full GC。

当新生代采用PSGC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否大于6MB，如小于，则触发对旧生代的回收。

除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java-Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

finalize()

在java.lang.Object里定义的，也就是说每一个对象都有这么个方法。这个方法在gc启动，该对象被回收的时候被调用。其实gc可以回收大部分的对象（凡是new出来的对象，gc都能搞定，一般情况下我们又不会用new以外的方式去创建对象），所以一般是不需要程序员去实现finalize的。特殊情况下，需要程序员实现finalize，当对象被回收的时候释放一些资源，比如：一个socket链接，在对象初始化时创建，整个生命周期内有效，那么就需要实现finalize，关闭这个链接。

使用finalize还需要注意一个事，调用super.finalize();一个对象的finalize()方法只会被调用一次，而且finalize()被调用不意味着gc会立即回收该对象，所以有可能调用finalize()后，该对象又不需要被回收了，然后到了真正要被回收的时候，因为前面调用过一次，所以不会调用finalize()，产生问题。所以，推荐不要使用finalize()方法，它跟析构函数不一样。

• object定义  protected void finalize() //定义为子类可见
• 执行时机不可预知

当一个对象变得不可触及时，垃圾回收器某个时期会回收此对象。

当回收对象之前会调用finalize方法，这类似于人类临终之前必须做一件事情：写遗言。

因为GC是不确定性的（这跟JVM相关），所以finalize方法的执行具有不可预知性。

• finalize忽略异常    即finalize代码中若出现异常,异常会被忽略
• finalize使用        什么时候使用?一般来说，finalize被作为第二种安全网来使用，如FileInputStream类， 当对象回收时，有可能资源为释放，所以这里第二次来确认（那也总比不释放强吧,虽然具体释放时机未定）
• protected void finalize() throws IOException { if (fd != null) { if (fd != fd.in) { close(); } } }
• 注意：某些用到finalize的地方，你必须像如下所示，显式调用回收链。protected void finalize() throws IOException { try{ ... }finally{ super.finalize(); }
• <\effective java>建议:尽量不要使用finalize，除非以它作为安全网，或是为了终结非关键的原生资源。

参考博文  https://www.cnblogs.com/wjtaigwh/p/6635484.html