小编点评

**问题分析** 1. 核心接口的压测QPS能够达到上千，但是实际执行的qps只有200左右。 2. 容器cpu飙升到100%，需要先定位cpu使用率问题，找出使用cpu最高的几个进程。 3. 通过top命令查找进程ID，发现正是压测的Java应用进程ID。 4. 通过jstack系统进程ID | grep 16进制线程ID命令找到对应的线程信息，发现该线程占用了一半左右的cpu。 5. 通过jmap -finalizerinfo 进程IDCount Class description进行分析发现，由于大量的业务对象通过CGLIB创建了动态代理类，而这些代理都是系统处理请求时创建的临时对象，请求完成后，这些临时对象就需要被垃圾回收掉，从而导致Finalizer线程执行频繁抢占了cpu资源。 **解决方案** 1. 不要使用CGLIB来给那些需要频繁进行垃圾回收的对象创建动态代理，可以手动创建静态代理类。 2. 对象复用，尽量减少临时对象的产生。 **其他建议** * 可以使用容器监控工具（例如Apache JMeter）来监控容器的性能，以便及时发现和解决问题。 * 可以使用GC监控工具来监控系统的GC行为，以便识别GC阻塞的问题。

正文

一、问题是怎么发现的

最近有个新系统开发完成后要上线，由于系统调用量很大，所以先对核心接口进行了一次压力测试，由于核心接口中基本上只有纯内存运算，所以预估核心接口的压测QPS能够达到上千。

压测容器配置：4C8G

先从10个并发开始进行发压，结果cpu一下就飙升到了100%，但是核心接口的qps才200左右。于是观察jvm的垃圾回收发现younggc很频繁，但是fullGC数量为零。

二、排查问题的详细过程

由于刚一开始压测，容器cpu就飙升到了100%，所以需要先定位cpu使用率问题，找出使用cpu最高的几个进程。可以通过top命令查找进程ID，发现正是压测的Java应用进程ID；然后在定位该金晨曦cpu使用率最高的线程，可以通过top -p 进程ID -H 命令显示该进程下的线程使用cpu信息。

top

top -p 进程ID -H

图片中PID列则为十进制显示的线程ID，然后转换为16进制；在通过jstack 系统进程ID | grep 16进制线程ID 命令找到对应的线程信息如下，也就是该线程占用了一半左右的cpu。

jstack 系统进程ID | grep 16进制线程ID

此时定位到了Finalizer线程，但是这个线程又有什么作用呢？

原来这个线程会不停的循环等待java.lang.ref.Finalizer.ReferenceQueue中的新增对象。一旦Finalizer线程发现队列中出现了新的对象，它会弹出该对象，调用它的finalize()方法，将该引用从Finalizer类中移除，因此下次GC再执行的时候，这个Finalizer实例以及它引用的那个对象就可以被垃圾回收掉了。如果这个线程一直在不停的工作，说明Finalizer的队列中有许多等待GC的垃圾对象。此时可以通过另一个命令来查看等待回收的垃圾对象有哪些。

jmap -finalizerinfo 进程ID

Count Class description
-------------------------------------------------------
32221 com.jd.price.deep.exact.entity.coupons.DeepExactCouponVo$$EnhancerByCGLIB$$200e6ee6
14908 com.jd.pricedoor.compute.promotion.MultiplePromotion$$EnhancerByCGLIB$$a59933de
11982 java.util.zip.Deflater
1 java.net.SocksSocketImpl

通过上述结果可以发现有好多的业务对象，通过类名可以看到这些对象都是通过CGLIB动态代理创建的，而且这些动态代理类都默认实现了finalize方法，导致这些对象在进行垃圾回收时必须先要执行finalize方法，所以都积压到了finalizer的队列中。

三、如何解决问题

通过上述排查过程发现，是由于大量的业务对象通过CGLIB创建了动态代理类，而这些代理都是系统处理请求时创建的临时对象，请求完成后，这些临时对象就需要被垃圾回收掉，从而导致Finalizer线程执行频繁抢占了cpu资源。

针对以上分析结果所以有了如下几种解决方案：

1.不要使用CGLIB来给那些需要频繁进行垃圾回收的对象创建动态代理，可以手动创建静态代理类。

2.对象复用，尽量减少临时对象的产生。

作者：京东零售 曹志飞

来源：京东云开发者社区