早上醒来便被系统报警短信施加了不小的压力，系统夜间多次报警，cpu使用率过高（超过90%），昨天晚上确实是上线了一个计算类的需求，不过算法相对简单（简单来说就是取两个字符串的公共子串，然后做一些处理),主观上认为不会因为这导致cpu爆掉，但是问题就是随着这个需求出现的，肯定拖不了干系，哎，bug排查往往就是这样，感觉某某地方不应该有问题，但是除了他又别无怀疑对象。
火急火燎的赶到公司，先申请了几台服务器扩容，缓解下压力，（leader也建议先下掉这个接口，但是我观察了这个接口的具体指标后，预估先扩下容，能撑住，撑不住再下，再则，下掉后，现象也会随之消失，更不利于排查问题）
扩容后，cpu和内存，都降到了可以接受的程度。
开始排查
1:单台服务器qps很低，个位数，可以放弃了。
2:想通过jstack看下，但是线上环境没权限执行这个命令，只能放弃
3:线下模拟，虽然感觉基本没用，毕竟上线之前，线下已经测试了，但是死马当作活马医，人总是会抱着万一的想法的，不过现实并不理想，由于没有跳出之前测试的思路，再次测试并没有突破。
4:真正没办法了，就该冷静下来了，既然公司不许线上环境使用jstack，jmap（确实也不应该允许使用，至少权限不能完全放开）,那么肯定又其他路子可以通向罗马，在公司群里吼了一嗓子后，发现果然是我太low，公司的监控系统是可以看到堆栈信息的（随便推荐下公司开源的监控系统cat，github地址：https://github.com/dianping/cat）
截图如下：
根据堆栈信息，找到相关代码，截图如下：
代码相对来说简单，但从代码来看，除了list的遍历写的不太友好（具体就不细说了，都应该能看出来）之外，并看不出什么。算了，先把能看到的解决了，
但是上线之后，问题依旧的话岂不是很尴尬，先测试下两种方式的效果再说吧，简单测试，发现list长度上万之后，效率才有差异，果断放弃这条线了（并不是不改，而是接着排查原因），这样基本就没啥可排查了，只有list很大了可查了，但是主观上是不信的，再大能有多大呢。按照之前的测试代码debug之后，list长度并无问题，测试和线上不一样的，也就只有入参了，对了，入参，去线上log中找了cpu报警时的入参，有亮点，比测试环境长很多，好歹有可测的地方了，debug之后，果然，这个入参，查处的list的size竟然有将近7千，其中绝大部分都是空，后面就好定位了，算法逻辑有问题，在入参较长的情况下，很容易暴漏出来（这个需求的场景中，一把都很短，自测也确实不够全面），修复之后，cpu降至个位数，搞定。
回头来看，问题本身很简单，但是前后排查缺花了近2个小时，让自己长个急性，留个爪
