WebService请求方式优化记录

由于公司项目使用人数暴增，导致项目的某些模块程序一直处于内存使用完，CPU使用率过高，导致程序处理缓慢，卡顿，并发能力大幅降低，于是不得不优化；

所有项目模块，也就只有请求第三方的程序模块存在这个问题，于是就开始进行处理；

 

1、查看CPU消耗过高的原因

大致流程是查看：占用CPU过高的进程 -> 进程中占有CPU的线程 -> 分析线程处理逻辑

按照流程进行操作，参考博客：JAVA CPU占用过高问题排查(linux)  

进行相关查看后，得出的结论是：内存使用完毕，FULL GC  频率很高，同时GC后没有释放空间，导致程序一直FULL GC，所以CPU也一直居高不下；

 

2、查看推内存中占用情况

通过 jmap -histo:live 26178 | more  命令，发现 com.sun.tools.javac.util.SharedNameTable.NameImpl 类及其实例所在的内存空间超级高，而且一直居高不下。

查询了网上相关资料：Java动态编译过程中的内存溢出问题 ，说是JVM自身的问题（JDK7~JDK8，JDK9解决），需要改动底层源码才能解决。

于是我们采取了两种方式进行尝试（1）改动JVM动态编译的参数设定；（2）使用了阿里的JDK ；

结果都失败了，程序还是没有明显改变；

 

3、修改程序JVM参数

通过上面操作，我们以为是我们程序程序没有问题，于是开始改动JVM参数，加大内存相关设置；

之前程序一个程序分配的是 4G内存，后面开始加大到6G，8G，加大内存后，确实要好很多，主要大部分时间CPU占用降了下来

但是用户数还是在猛增，发现加大内存，只是延缓了一些FULL GC的时间间隔，但是没有从实际上解决问题，后面程序还是压力很大，CPU一直居高不下；

 

4、扩展服务器

因为暂时找不到比较明显的原因，为了保证程序还能运行，于是把有问题的程序部署机器扩展到了10多台，还真是没有办法；

 

5、请求方式改动

研究了很多以后，知道原因是JDK动态编译过程太多，导致动态编译的相关程序导致的，于是分析之后，确定了代码最大的问题是出自第三方的请求方式问题，我们实际使用的也是CXF动态客户端的生成方式。于是我们重新写了一套请求方式，采用CXF的静态请求方式，然后对这两段代码进行压测，发现XCF静态请求方式的性能远远超出动态客户端的方式，不会在导致CPU占比过高，从而导致服务处理阻塞。压测请求如下（每秒300请求，连续请求5分钟，堆内存设置是4G，年轻代：年老代=1：2）：

    

• CXF静态客户端方式

   

  

• XCF动态客户端方式

   

  

 

6、压测后，请求方式全部切换为CXF静态请求方式，完美解决CPU过高问题。