关于jvm中的gc fullgc的理解

2023-10-06 22:58:16

什么是垃圾回收机制

任何语言在运行过程中都会创建对象，也就意味着需要在内存中为这些对象在内存中分配空间，在这些对象失去使用的意义的时候，需要释放掉这些内容，保证内存能够提供给新的对象使用。对于对象内存的释放就是垃圾回收机制，也叫做gc。

java的垃圾回收机制是自动化的，但是可控性很差，甚至有时会出现内存溢出的情况，
内存溢出也就是jvm分配的内存中对象过多，超出了最大可分配内存的大小。

内存的区域

新生代：新生代的目标就是尽可能快速的手机掉那些生命周期短的对象，一般情况下，所有新生成的对象首先都是放在新生代的。

老年代：老年代存放的都是一些生命周期比较长的对象，就像上面所叙述的那样，在新生代中经历了n次垃圾回收后仍然存活的对象就会被放到老年代中。此外，老年代的内存也比新生代大很多（比例大概是1：2），当老年代满时就会触发major GC（full GC），老年代对象存货时间比较长，因此full GC发生的频率比较低。

注意:
在jdk8的时候java废弃了永久代，但是并不意味着我们以上的结论失效，因为java提供了与永久代类似的叫做“元空间”的技术。
废弃永久代的原因：由于永久代内存经常不够用或发生内存泄露，爆出异常java.lang.OutOfMemoryErroy。元空间的本质和永久代类似。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。也就是不局限与jvm可以使用系统的内存。理论上取决于32位/64位系统可虚拟的内存大小。

解读GC日志

以其中一行为例来解读下日志信息：

[GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 522739K->156516K(1322496K), 0.0025301 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

GC：

表明进行了一次垃圾回收，前面没有Full修饰，表明这是一次Minor GC ,注意它不表示只GC新生代，并且现有的不管是新生代还是老年代都会STW。（Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；这些现象多半是由于gc引起。）

Allocation Failure：

表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

ParNew：

表明本次GC发生在年轻代并且使用的是ParNew垃圾收集器。ParNew是一个Serial收集器的多线程版本，会使用多个CPU和线程完成垃圾收集工作（默认使用的线程数和CPU数相同，可以使用-XX：ParallelGCThreads参数限制）。该收集器采用复制算法回收内存，期间会停止其他工作线程，即Stop The World。

367523K->1293K(410432K)：单位是KB

三个参数分别为：GC前该内存区域(这里是年轻代)使用容量，GC后该内存区域使用容量，该内存区域总容量。

0.0023988 secs：

该内存区域GC耗时，单位是秒

522739K->156516K(1322496K)：

三个参数分别为：堆区垃圾回收前的大小，堆区垃圾回收后的大小，堆区总大小。

0.0025301 secs：

该内存区域GC耗时，单位是秒

[Times: user=0.04 sys=0.00, real=0.01 secs]：

分别表示用户态耗时，内核态耗时和总耗时

分析下可以得出结论：

该次GC新生代减少了367523-1293=366239K

Heap区总共减少了522739-156516=366223K

366239 – 366223 =16K，说明该次共有16K内存从年轻代移到了老年代，可以看出来数量并不多，说明都是生命周期短的对象，只是这种对象有很多。

我们需要的是尽量避免Full GC的发生，让对象尽可能的在年轻代就回收掉，所以这里可以稍微增加一点年轻代的大小，让那17K的数据也保存在年轻代中。

Minor GC和Full GC的区别以及触发条件：

Minor GC:

对于复制算法来说，当年轻代Eden区域满的时候会触发一次Minor GC，将Eden和From Survivor的对象复制到另外一块To Survivor上。

注意：如果某个对象存活的时间超过一定Minor gc次数会直接进入老年代，不在分配到To Survivor上(默认15次，对应虚拟机参数 -XX:+MaxTenuringThreshold)。

Full GC:

用于清理整个堆空间。它的触发条件主要有以下几种：

显式调用System.gc方法(建议JVM触发)。
方法区空间不足(JDK8及之后不会有这种情况了，详见下文)
老年代空间不足，引起Full GC。这种情况比较复杂，有以下几种：
3.1 大对象直接进入老年代引起，由-XX:PretenureSizeThreshold参数定义

3.2 Minor GC时，经历过多次Minor GC仍存在的对象进入老年代。上面提过，由-XX:MaxTenuringThreashold参数定义

3.3 Minor GC时，动态对象年龄判定机制会将对象提前转移老年代。年龄从小到大进行累加，当加入某个年龄段后，累加和超过survivor区域 * -XX:TargetSurvivorRatio的时候，从这个年龄段往上的年龄的对象进入老年代

3.4 Minor GC时，Eden和From Space区向To Space区复制时，大于To Space区可用内存，会直接把对象转移到老年代

JVM的空间分配担保机制可能会触发Full GC：

在进行Minor GC之前，JVM的空间担保分配机制可能会触发3.2、3.3和3.4发生，即触发一次Full GC。

空间担保分配是指在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

如果大于，则此次Minor GC是安全的。

如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的，失败后会重新发起一次Full gc；如果小于或者HandlePromotionFailure=false，则改为直接进行一次Full GC。

所有才会说一次Full GC很有可能是由一次Minor GC触发的。

频繁FullGC可能的问题

1. LinkedBlockingQueue$Node

当数据量很大时，LinkedBlockingQueue会无限制存放数据，最终导致Allocation Failure的Full GC。

2.线程池

使用Executors.newFixedThreadPool(nThreads)构造线程池处理消息，结果由于消息量很大，造成内存消耗过快，频繁FULL GC，其本质原因也是队列无限存放数据。

3.每次请求消耗的内存量过大

4.也有可能是VM堆内存分配过低

复制粘贴自：https://blog.csdn.net/zc19921215/article/details/83029952

https://blog.csdn.net/weixin_39067991/article/details/81045201

https://www.cnblogs.com/lupeng2010/p/8252970.html

码农公寓