华清远见-嵌入式人工智能

download：https://www.zxit666.com/6456/

一、问题是怎样发现的

最近有个新系统开发完成后要上线，由于系统调用量很大，所以先对中心接口停止了一次压力测试，由于中心接口中根本上只要纯内存运算，所以预估中心接口的压测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 进程IDCount Class description -------------------------------------------------------32221 com.jd.price.deep.exact.entity.coupons.DeepExactCouponVo$$EnhancerByCGLIB$$200e6ee614908 com.jd.pricedoor.compute.promotion.MultiplePromotion$$EnhancerByCGLIB$$a59933de11982 java.util.zip.Deflater1 java.net.SocksSocketImpl

经过上述结果能够发现有好多的业务对象，经过类名能够看到这些对象都是经过CGLIB动态代理创立的，而且这些动态代理类都默许完成了finalize办法，招致这些对象在停止渣滓回收时必需先要执行finalize办法，所以都积压到了finalizer的队列中。

三、如何处理问题

经过上述排查过程发现，是由于大量的业务对象经过CGLIB创立了动态代理类，而这些代理都是系统处置恳求时创立的暂时对象，恳求完成后，这些暂时对象就需求被渣滓回收掉，从而招致Finalizer线程执行频繁抢占了cpu资源。

针对以上剖析结果所以有了如下几种处理计划：

1.不要运用CGLIB来给那些需求频繁停止渣滓回收的对象创立动态代理，能够手动创立静态代理类。

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