CPU 优化线上实战篇：Java 生产环境 CPU 跑满 & 大量长耗时的问题排查 & 解决

本文正在参加「Java应用线上问题排查经验/工具分享」活动

背景

公司某渠道系统，专门对接三方渠道使用，没有什么业务逻辑，主要是转换报文和参数校验之类的工作，起着一个承上启下的作用。

就在今天早上，突然监控告警了……该系统的所有机器，CPU 利用率达到90%+，并且出现大面积的长耗时请求

这种突然长耗时的情况，对于问题排查来说还是挺常见的，所以我还是按照惯例，先分析事件背景：

和相关负责人沟通后，得知2/3两处并没有问题，但确实有激增流量的情况。

有一个和渠道系统交互的周边系统，最近在早上有批量调用渠道系统的问题，不过并发请求并不多，不太可能把这个系统所在机器 CPU 打满……

但事已至此，光怀疑没有用，得拿出实际的证据来。

虽然 CPU 利用率高和慢响应是两个问题，但这俩问题一般是关联的，很可能是 CPU 利用率过高导致的慢响应，所以还是先从 CPU 利用率这个问题出发，看能不能找到一些蛛丝马迹。

于是我们又给该系统新建了一套新的临时测试环境，用于复现问题。场景上尽可能的还原早上的激增流量，不过这里为了排查简单，我们这里做了等比缩小。

比如100并发、10台机器的生产环境，我们用了10+并发，1台机器去模拟，这样监控之类的工作就简单很多了，复现问题也会更简单。

经过测试后发现，等比缩小后的配置仍然会导致 CPU 飙高，直接快 90% 了。

既然能这么稳定的复现问题，那可就好办了。top 命令或者其他监控工具，看一下该进程的哪个线程 CPU 利用率高，然后在查一下该线程的 StactTrace，看看这个线程在搞什么花样（工具啥的这里就不介绍了，命令行的，图形界面的一堆）……

经过分析线程的 stacktrace 发现，占用高的线程基本都在执行 Castor 的相关代码。

Castor 是一个 XML 映射&转换的库，功能非常丰富，可以用配置的方式将 XML 格式转换为异构的 POJO。

渠道系统嘛，拿这玩意转换报文，很正常。

但为什么这个东西 CPU 会占用这么高？这点并发量完全不至于，况且在调用 castor 转换完报文后，后面还有调用核心系统接口的动作，并不是一直在转换报文，这点并发量不可能把 CPU 跑这么高。

一个成熟的开源项目，性能怎么可能这么差呢？要是性能差成这样，那肯定也没人用了。

于是，我开始怀疑……是不是用法不对？

先看看渠道系统代码里的用法：

public static Object readXML2Bean(Mapping mapping, String xmlString, Class<?> beanClass) throws Exception {
StringReader reader = new StringReader(xmlString);
Unmarshaller unmar = new Unmarshaller(beanClass);
unmar.setMapping(mapping);
Object ob = unmar.unmarshal(reader);
reader.close();
return ob;
}