GC回收算法、堆参数调优

最新推荐文章于 2024-08-12 16:59:53 发布

Keep hunger

最新推荐文章于 2024-08-12 16:59:53 发布

阅读量208

点赞数

分类专栏： Java

本文链接：https://blog.csdn.net/ITgagaga/article/details/108763755

版权

Java 专栏收录该内容

23 篇文章 0 订阅

订阅专栏

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回收算法

1.引用计数法

给对象添加一个引用计数器，每当一个地方引用它时，计数器加1，每当引用失效时，计数器减少1.当计数器的数值为0时，也就是对象无法被引用时，表明对象不可在使用，这种方法实现简单，效率较高，大部分情况下不失为一个有效的方法。但是主流的Java虚拟机如HotSpot并没有选取引用计数法来回收内存，主要的原因难以解决对象之间的相互循环引用的问题

2.复制算法

年轻代中的GC,主要是复制算法（Copying）

在这里插入图片描述

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.一般情况下效率比较高

缺点

1、浪费了一半的内存。
2、在极端情况下，将对象从from区复制到to区，浪费的时间不能忽视

3.标记清除算法

老年代一般是由标记清除或者是标记清除与标记整理的混合实现

用通俗的话解释一下标记清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。

主要进行两项工作，第一项则是标记，第二项则是清除。
标记：从引用根节点开始标记遍历所有的GC Roots，先标记出要回收的对象。
清除：遍历整个堆，把标记的对象清除。

优点

不浪费内存

缺点

1、效率低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序
2、空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

4.标记整理算法

在这里插入图片描述

在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

优点

标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价

缺点

标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。
从效率上来说，标记/整理算法要低于复制算法。

二.总结

内存效率：复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法=标记整理算法>标记清除算法。
内存利用率：标记整理算法=标记清除算法>复制算法。

可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程。所以最适合的算法就是分代收集算法：

年轻代(Young Gen)

年轻代特点是区域相对老年代较小，对像存活率低。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)

老年代的特点是区域较大，对像存活率高。

这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

标记阶段的开销与存活对像的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率。

清除阶段的开销与所管理区域的大小形正相关，但清除“就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

压缩阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一选择并不合适。

基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以hotspot中的CMS回收器为例，CMS是基于Mark-Sweep（标记清除）实现的，对于对像的回收效率很高，而对于碎片问题，CMS采用基于Mark-Compact（标记压缩）算法的Serial Old回收器做为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。

三.堆参数调优

在这里插入图片描述

在Java8中，永久代已经被移除，被一个称为元空间的区域所取代。元空间的本质和永久代类似。元空间与永久代之间最大的区别在于：**永久带使用的JVM的堆内存，但是java8以后的元空间并不在虚拟机中而是使用本机物理内存。**因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。

1.堆空间调整参数

参数名称	描述
-Xms	设置堆的初始内存大小，默认是物理内存的1/64
-Xmx	设置堆的最大分配内存，默认是物理内存的1/4
-XX:+PrintGCDetails	打印详细的GC处理日志
-XX:+PrintGCTimeStamps	输出GC的时间戳信息
-XX:+PrintGCDateStamps	以日期的形式输出GC的时间信息
-XX:+PrintHeapAtGC	打印GC处理的前后堆内存信息
-Xloggc:保存路径	设置日志文件的保存位置
-Xmn	Java Heap Young区大小，不熟悉最好保留默认值
-Xss	每个线程的Stack大小，不熟悉最好保留默认值
-XX:NewSize	设置JVM堆的‘新生代’的默认大小
-XX:MaxNewSize	设置JVM堆的‘新生代’的最大大小
-XX:PermSize	设定内存的永久保存区域（jdk1.7）
-XX:MaxPermSize	设定最大内存的永久保存区域（jdk1.7）

2.获取堆内存信息

//获取cpu核数
int i = Runtime.getRuntime().availableProcessors();
System.out.println(i);

//JVM最大可利用内存 物理内存的4/1
long maxMemory = Runtime.getRuntime().maxMemory();

//JVM默认使用的内存 物理内存的64/1
long totalMemory = Runtime.getRuntime().totalMemory();

//当前JVM空闲内存 
Runtime.getRuntime().freeMemory(); 

System.out.println("可使用最大内存："+maxMemory+"(字节)  "+maxMemory/(double)1024/1024/1024+"(GB)");
System.out.println("JVM默认使用的内存："+totalMemory+"(字节)  "+totalMemory/(double)1024/1024/1024+"(GB)");

3.调整堆参数

3.1 将默认内存和最大内存都调整为4/1

默认空余堆内存小于 40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、 -Xmx相等以避免在每次GC 后调整堆的大小。

3.2 非堆内存调整

java8中元空间已经取代了永久代。元空间并不在虚拟机内存中，而是使用本机物理内存。类的元数据放入native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。

3.3 JVM内存限制(最大值)

在IDEA中Run->Configurations->VM options中写入堆参数：-Xms1024m -Xmx1024m -XX:+PrintGCDetails

IDEA：
前：
可使用最大内存：2841116672(字节)  2.64599609375(GB)
JVM内存总量：192937984(字节)  0.1796875(GB)

后：
可使用最大内存：1029177344(字节)  0.95849609375(GB)
JVM默认使用的内存：1029177344(字节)  0.95849609375(GB)

4.三种内存溢出异常介绍

1. OutOfMemoryError： Java heap space 堆溢出

内存溢出主要存在问题就是出现在这个情况中。当在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。

2. OutOfMemoryError： PermGen space 非堆溢出（永久保存区域溢出）

这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。

3. OutOfMemoryError： unable to create new native thread. 无法创建新的线程

这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。这种怪事是因为JVM已经被系统分配了大量的内存（比如1.5G），并且它至少要占用可用内存的一半。

5.查看GC日志

可以使用一些离线的工具来对GC日志进行分析，比如sun的gchisto( https://java.net/projects/gchisto)，gcviewer（ https://github.com/chewiebug/GCViewer ），这些都是开源的工具，用户可以直接通过版本控制工具下载其源码，进行离线分析。

String str="aaaaa";
        while (true){
            str+=str+new Random().nextInt(8888888)+new Random().nextInt(888889988);
        }


[GC (Allocation Failure) [PSYoungGen: 2032K->504K(2560K)] 2032K->704K(9728K), 0.0063131 secs] [Times: user=0.00 sys=0.02, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 2430K->504K(2560K)] 2630K->1215K(9728K), 0.0048540 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1886K->480K(2560K)] 2598K->1952K(9728K), 0.0055010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1863K->472K(2560K)] 4679K->3959K(9728K), 0.0052322 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 1183K->424K(2560K)] 6015K->5255K(9728K), 0.0023898 secs] [Times: user=0.03 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 424K->440K(1536K)] 5255K->5271K(8704K), 0.0038928 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 440K->0K(1536K)] [ParOldGen: 4831K->2671K(7168K)] 5271K->2671K(8704K), [Metaspace: 3501K->3501K(1056768K)], 0.0191581 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 40K->32K(2048K)] 6743K->6735K(9216K), 0.0015760 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 32K->0K(2048K)] [ParOldGen: 6703K->1999K(7168K)] 6735K->1999K(9216K), [Metaspace: 3501K->3501K(1056768K)], 0.0179471 secs] [Times: user=0.05 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 19K->0K(2048K)] 6051K->6031K(9216K), 0.0010948 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 6031K->6031K(9216K), 0.0007082 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 6031K->4687K(7168K)] 6031K->4687K(9216K), [Metaspace: 3501K->3501K(1056768K)], 0.0058093 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 4687K->4687K(9216K), 0.0020195 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 4687K->4666K(7168K)] 4687K->4666K(9216K), [Metaspace: 3501K->3501K(1056768K)], 0.0495211 secs] [Times: user=0.01 sys=0.02, real=0.05 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
	at java.lang.StringBuilder.append(StringBuilder.java:208)
	at JVM01.main(JVM01.java:17)
Heap
 PSYoungGen      total 2048K, used 60K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 1024K, 5% used [0x00000000ffd00000,0x00000000ffd0f330,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 7168K, used 4666K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 65% used [0x00000000ff600000,0x00000000ffa8eb88,0x00000000ffd00000)
 Metaspace       used 3533K, capacity 4502K, committed 4864K, reserved 1056768K
  class space    used 391K, capacity 394K, committed 512K, reserved 1048576K