| 背景
前段时间我们的服务遇到了性能瓶颈，由于前期需求太急没有注意这方面的优化，到了要还技术债的时候就非常痛苦了。
在很低的 QPS 压力下服务器 load 就能达到 10-20，CPU 使用率 60% 以上，而且在每次流量峰值时接口都会大量报错，虽然使用了服务熔断框架 Hystrix，但熔断后服务却迟迟不能恢复。每次变更上线更是提心吊胆，担心会成为压死骆驼的最后一根稻草，导致服务雪崩。
在需求终于缓下来后，leader 给我们定下目标，限我们在两周内把服务性能问题彻底解决。近两周的排查和梳理中，发现并解决了多个性能瓶颈，修改了系统熔断方案，最终实现了服务能处理的 QPS 翻倍，能实现在极高 QPS（3-4倍）压力下服务正常熔断，且能在压力降低后迅速恢复正常，以下是部分问题的排查和解决过程。
| 服务器高CPU、高负载
首先要解决的问题就是服务导致服务器整体负载高、CPU 高的问题。
我们的服务整体可以归纳为从某个存储或远程调用获取到一批数据，然后就对这批数据进行各种花式变换，最后返回。由于数据变换的流程长、操作多，系统 CPU 高一些会正常，但平常情况下就 CPU us 50% 以上，还是有些夸张了。
我们都知道，可以使用 top 命令在服务器上查询系统内各个进程的 CPU 和内存占用情况。可是 JVM 是 Java 应用的领地，想查看 JVM 里各个线程的资源占用情况该用什么工具呢？
jmc 是可以的，但使用它比较麻烦，要进行一系列设置。我们还有另一种选择，就是使用 jtop，jtop 只是一个 jar 包，它的项目地址在 y