问题描述

  • 问题1： 我们的网关服务在发布刚启动的时候，总是会报几次fullgc，并且会引起少量请求超时。

  • 问题2.：同时服务在某些时间点会报出较多的超时异常，在cat监控上观察到超时异常和fullgc时间点吻合，fullgc耗时在600ms左右，那么至少fullgc停顿时间是造成短时间内大量超时的因素。并且观察到old区内存非常缓慢的线性增长，在达到old区内存92%左右时，触发fullgc，old内存开始占用很小。并且从eden区young gc稳定，每次young gc后eden内存基本都可以回收， 所以当时初步判断进入eden区的对象应该是由于每次younggc少量对象因gc年龄太大而晋升。

  • 问题3： fullgc时间600ms左右，时间过长

JVM运行参数：

-XX:InitialHeapSize=4244635648 -XX:MaxHeapSize=4244635648 -XX:MaxNewSize=1414529024 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=1414529024 -XX:OldSize=2830106624 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC

老年代回收默认使用了ParallelOld收集器

排查

调整JVM参数，打印gc详细日志，其它JVM参数没有变化。在线下环境进行压测，观察到服务刚启动时，下图红框显示了fullgc的原因是 Metadata GC Threshold。

因为使用ParallelOld收集器即使加上参数也无法打印survivor区的对象年龄分布，只能显示desired survivor size。所以启用CMS收集器进行压测成功打印了age分布信息

登上线上机器查看当前进程里对象占用内存的前20排名


[bbb@aaa bin]$ ./jmap -histo:live 6258 | head -20

 num  #instances  #bytes class name

----------------------------------------------

 1:  26715  25520840 [I

 2: 215586  24046568 [C

 3:  95269  18935792 [B

 4:  69325 7764400 java.net.SocksSocketImpl

 5: 108223 6844216 [Ljava.lang.Object;

 6: 395157 6322512 java.lang.Object

 7: 213313 5119512 java.lang.String

 8: 125955 4030560 java.util.concurrent.ConcurrentHashMap$Node

 9:  69319 3327312 java.net.SocketInputStream

 10:  69319 3327312 java.net.SocketOutputStream

 11:  36674 3227312 java.lang.reflect.Method

 12:  98415 3149280 java.util.HashMap$Node

 13:  69833 2793320 java.lang.ref.Finalizer

 14: 106620 2558880 java.net.InetAddress$InetAddressHolder

 15: 106614 2558736 java.net.Inet4Address

 16:  31185 2536648 [Ljava.util.HashMap$Node;

 17:  59156 2366240 java.util.LinkedHashMap$Entry

dump内存后进行分析，在dominator_tree中可以看到大对象Finalizer的Retained Heap列是指该对象GC之后所能回收到内存的总和，可以看出由Finalizer关联的引用所占的空间最多。

在histogram视图中可以看到占用内存前几高的对象都是和socket相关的

查看dump内存中的不可达对象中，org.apache.commons.pool.impl.CursorableLinkedList$Listable对象非常多。

在支配树中查看该对象的引用关系发现Listable中存的value是GenericKeyedObjectPool的内部类ObjectTimestampPair，ObjectTimestampPair中存的value指向的是thrift通信所用的TSocket， TSocket中封装着jdk的java.net.Socket。Socket中使用的SocketImpl的实现是SocksSocketImpl，在SocksSocketImpl的父类AbstractPlainSocketImpl中，重写了finalize()方法，从注释可以看出来，该方法的作用是：为了防止用户忘记关闭资源，当SocksSocketImpl被回收时，finalize被调用执行清理工作，SocksSocketImpl的close()方法体中也是直接调用AbstractPlainSocketImpl的close()。

原因

启动时fullgc

MetaspaceSize初始值过小

线上设置-XX:MetaspaceSize初始值过小，metaspace会在-XX:MaxMetaspaceSize范围内动态扩容，在启动过程中，每次fullgc后也观察到了commit 的 metaspace空间变大了。（在这里当时观察到fullgc后，整个新生代对象全部清空了，老年代大了非常多，难道本该进入survivor区的都进入了老年代？？？）

其它可能原因

-XX:TargetSurvivorRatio为单个survivor区的目标存活率

Desired survivor size = (survivor_capacity _TargetSurvivorRatio) / 100 _sizeof(a pointer)：survivor_capacity（一个survivor space的大小）乘以TargetSurvivorRatio

正常默认desired survivor size 是一个survivor space的50%，线上默认没有启用-XX: +UseAdaptiveSizePolicy，参数意味着eden区和survivor区的比例是动态调整的，从gc日志也能观察到某时刻survivor区可能非常小，很容易导致survivor区溢出，survivor之所以动态调整是因为希望系统尽可能的满足系统吞吐量。

如果所有age的survivor space对象的大小如果超过Desired survivor size，则重新计算threshold，以age和MaxTenuringThreshold的最小值为准，否则以MaxTenuringThreshold为准，即为了满足设定的survivor区的目标存活率，JVM会自动调整MaxTenuringThreshold。比如年龄从1-7的对象总和已经>Desired survivor size，那么TenuringThreshold 可能降低为6，生怕survivor区溢出。那么把survivor区适当调大，TenuringThreshold值就可能到达15，长期存活对象就越有可能在新生代被回收。

老年代缓慢增长

NettyIO和ThriftIO 的连接池

由于tcp连接频繁创建代价非常大，所以有了长连接和连接池技术。我们目前线上使用的原生的thriftIO（TNonblockingSocket），使用上面提到的apache的对象池 GenericKeyedObjectPool 的实现来缓存建立的连接，看了下我们连接池的参数配置，

minIdle=1，

MaxIdle=5，

maxActive=300，

连接池队列使用FIFO管理池对象

minEvictableIdleTimeMillis为30分钟，默认30分钟后，连接从池中销毁

意味着

1. 在qps较低的时候（夜间）大量请求都会使用池的头部链接，后部连接会因为到达evict时间而被销毁

2. 在qps较高的时候，池对象无空闲，500ms后在小于maxActive情况下创建新的连接，并使用完后立刻销毁无法复用

3. 查看我们younggc每分钟频次，在30分钟内对象年龄分布中超过15完全有可能，即很可能出现SocksSocketImpl对象频繁晋升老年代

4. Finalizer的Retain Heap之所以那么大，也是因为内存中存在大量SocksSocketImpl对象

4. socket对象内部的byte[]也会随着进入老年代

ThriftIO情况下，每个请求独占一个socket连接，当基于该连接的请求在服务端处理时，该连接空闲率增加。

NettyIO情况下，多个请求同一时刻可以复用同一个channel来传输数据，意味着同样qps下，NettyIO会创建较少的连接数

ThriftIO的池化依赖的apache common pool，使用 TNonblockingSocket 作为 TTransport 层

NettyIO的池化由公司自研，看了下其实现Netty连接池的原理，大体原理是：

1. 设定池大小的最小最大配置

2. 将池对象Channel放到数组或List中，每个请求都从池中随机选择一个Channel（很可能选择的是同一个）

3. 两个ConcurrentHashMap中，一个保存写出的消息ID和Callback，另一个包含消息ID和 LinkedBlockingQueue，这样解决了多线程操作channel响应结果到底是哪个线程的问题

3. 业务线程使用Netty的Channel作为thrift的 TTransport 层进行writeAndFlush发送消息

4. 业务线程blcok在从LinkedBlockingQueue中获取结果

5. Netty的某ClientHandler解码后进行callback调用，并添加结果到LinkedBlockingQueue

6. 阻塞的业务线程返回 进行处理

Finalizer原理

因为SocksSocketImpl 对象实现了finalize方法，JVM在java 对象创建过程中识别出其实现了finalize方法，会将其封装成Finalizer对象，Finalizer是一个双向链表，并添加到Finalizer链表中，这样有Finalizer引用存在，SocksSocketImpl 对象即使已经无用也不会被回收。

Finalizer的祖父类Refrence有一个ReferenceHandler线程，来完成将Finalizer新添加的对象加入到RefrenceQueue中，该线程具体执行时机是在 pending 字段被设置的时候，即会在GC线程进行第一次标记的时候，接着RefrenceQueue在enquery方法中通过 notifyAll 方法唤醒 FinalizerThread 线程执行后续逻辑， FinalizerThread 是在 Finalizer 类的静态代码块中会创建一个 FinalizerThread 类型的守护线程，但是这个线程的优先级比较低，意味着在cpu吃紧的时候可能会抢占不到资源执行。实现如下

FinalizerThread 线程干的事情就是执行对象实现的finalize方法，然后将Finalizer对象从Finalizer链表中删除

意味着如果在执行finalize方法时，对象没有再次赋给强引用，现在也没有了Finalizer引用，那么在下一次GC时，便会被真正的回收，即实现finalize方法的对象的回收至少需要两次gc，而 FinalizerThread 执行优先级非常低，

SocksSocketImpl 的父类重写了 finalize 方法，这么做主要是为了确保在用户忘记手动关闭 socket 连接的情况下，在该对象被回收时能够自动关闭 socket 来释放一些资源，但是在开发过程中，真的忘记手动调用了 close 方法，那么这些 socket 对象可能会因为 FinalizeThread 线程迟迟没有执行到这些对象的 finalize 方法，而导致一直占用某些资源，造成内存泄露。

fullgc耗时较长

线上没有采用 更关注系统响应时间CMS收集器，同时有可能标记大量Finalizer对象的处理耗时较多，毕竟Finalizer对象数量很大。

如果采用CMS收集器，那么CMS FinalMarking（并发重新标记，STW过程）进行如下的处理：

  1. 遍历新生代对象，重新标记

  2. 根据GC Roots，重新标记

  3. 遍历老年代的Dirty Card，重新标记，这里的Dirty Card大部分已经在clean阶段处理过

在第一步骤中，需要遍历新生代的全部对象，如果新生代的使用率很高，�