CPU消耗过高的问题

最近项目进入了压力测试阶段，测试中发现了一个相当辣手的问题，经过我和同事接近两天的仔细分析检查终于找到了问题原因，干掉了那个可恶的BUG。在此特写总结以醒自己！

项目的功能主要是用于接收外系统送过来的交易数据，该项目已经在生产使用，本次只是动作较大的一次改造。项目基于JAVA开发，数据库使用的ORACLE，服务器使用的WEBSPHERE，整个项目部署于LINUX系统上。生产的系统每天大概有4万笔的业务量，运行稳定。

当测试开始后，我们将系统发布至服务器，开始系统运行状态良好，速度很快。可是随着时间的推移，业务量的增加，整个系统的响应速度就变得越来越慢，最后处理一笔交易基本需要10秒钟，简直难以忍受，经过监控分析，我们发现系统的CPU消耗也来越高，最高可以到达196%，の难以置信。。

为什么CPU消耗会这么高？那里会这么耗CPU？ 难道是存在死循环？ 疑惑。。。

因为CPU消耗过高所以导致整体业务处理速度下降，所以我们着手查找CPU消耗过高的原因。由于这次只是改造，虽然改动较大，但是大部分程序还是没有变化的，所以从本次新增的程序着手分析。。

由于这次新增了XML报文转换模块，之前系统用的都是定长报文，所以开始重点分析该模块。报文转换模块我们使用了JDK带的JAXB实现，另外又加了自己开发的BEAN转换功能，就是将JAXB生成的BEAN转换为系统所使用的通用BEAN对象，考虑到BEAN转换功能用到了反射、循环等，所以重点分析这块程序，经过分析优化，BEAN转换功能减少了循环次数，提高了一点点的效率，但还是没有实质效果，所以放弃对该模块的怀疑，开始分析JAXB转换模块。经过测试发现，在多线程并发转换的情况下，CPU真的就上去了，当初看到这样的结果，我们还以为真是JAXB的问题，后面又在网上找了相关的资料，有网友提示JAXBContext 最好是使用单例的，如果每次使用时再实例化就会相当消耗资源，于是我们修改了程序，结果发现程序处理效率又有了一定好转，于是我们将程序重新发布做测试，の，悲剧依然存在，CPU仍旧居高不下。当天已经晚上11点了，无奈打的回家，第二天再处理。。

第二天用清醒的头脑重新分析问题原因，针对本次所新增修改的程序逐段屏蔽测试，结果又发现了一个WEBSERVICE调用响应速度慢的问题，可是考虑到系统流程环境确实较多，所以断定WEBSERVICE调用慢应该不是问题。最后继续逐段分析程序，并拿出DUMP日志分析，结果又发现了一个字符串拼接的问题，针对字符串拼接耗时，我们做了如下试验：
代码1、使用String累加的方式，进行50000次拼接：

 1 long i = System.currentTimeMillis();
 2 String tmp = "";
 3 for (int k = 0; k < 50000; k++)
 4 {
 5 tmp += " ";
 6 }
 7 long j = System.currentTimeMillis();
 8 System.out.println("use time:" + (j - i));
 
 结果：use time:1469

代码2、使用StringBuilder拼接的方式，进行50000次拼接：

1 long ii = System.currentTimeMillis();
2 StringBuilder tmpBuf = new StringBuilder("");
3 for (int k = 0; k < 1000000; k++)
4 {
5 tmpBuf.append(" ");
6 }
7 long jj = System.currentTimeMillis();
8 System.out.println("use time： + (jj - ii));

结果：use time：6

结果如上所示，差距真的很大！所以对于字符串拼接最好不要使用直接累加的方式。。。

总结：
1、使用JAXB做XML BEAN转换时，记得JAXBContext应该设为单例的，这样可以提高转换效率；
2、所有字符串拼接一定要使用StringBuilder(非线程安全，速度更快)或StringBuffer(线程安全)；
3、DUMP日志的获取方法，LINUX 下执行kill -3 PID 然后日志就会产生，如果使用的时WAS带的JDK那么日志所在位置应类似：/opt/IBM/WebSphere/AppServer/profiles/AppSrv01；
5、写程序一定要认真，敲代码的速度没必要那么快，代码质量最重要；
6、查找问题的方法：平心精气、不要慌张，仔细分析问题原因，可以通过获取DUMP日志的方式确定问题所在，实在无法确定问题所在时，需要使用大量记录日志、或逐段屏蔽程序的方式测试分析；

转载于:https://www.cnblogs.com/imarc/archive/2012/05/26/2519535.html