2019双11还有不到2个月就要到来了，大家也都知道服务器在大促期间由于流量的增加势必导致机器的cpu与load变高。因此趁着这个时机正好再好好学习、巩固一下cpu和load的概念，为双11做准备的同时也是增加自己的技能储备。
不过cpu和load这块真的还是很需要积累的，我自己经验尚浅，感觉还是有许多写的不到位与不对的地方，也是希望如果有错误，大家可以帮助指正。
top命令
既然说了cpu和load，那总需要监控吧，没有监控就不知道cpu和load，后面的一切也就无从谈起了。
做了一张表格比较详细地解释了每一部分的含义，其中重要属性做了标红加粗：
内存与SWAP输出格式是一样的，因此放在了一起写。
cpu如何计算
当我们执行top命令的时候，看到里面的值（主要是cpu和load）值是一直在变的，因此有必要简单了解一下Linux系统中cpu的计算方式。
cpu分为系统cpu和进程、线程cpu，系统cpu的统计值位于/proc/stat下（以下的截图未截全）：
cpu、cpu0后面的这些数字都和前面的us、sy、ni这些对应，具体哪个对应哪个值不重要，感兴趣的可以网上查一下文档。
进程cpu的统计值位于/proc/{pid}/stat下：
线程cpu的统计值位于/proc/{pid}/task/{threadId}/stat下：
对load的理解
一个单核的处理器可以形象得比喻成一条单车道，车辆依次行驶在这条单车道上，前车驶过之后后车才可以行驶。如果前面没有车辆，那么你顺利通过；如果车辆众多，那么你需要等待前车通过之后才可以通过。因此，需要些特定的代号表示目前的车流情况，例如：·等于0.00，表示目前桥面上没有任何的车流。实际上这种情况0.00和1.00之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过·等于1.00，表示刚好是在这座桥的承受范围内。这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢·大于1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。那么情况有多糟糕例如2.00的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待但是比喻终归是比喻，从比喻中我们了解了，load表示的是系统的一个能力，但是我们却不知道什么样的任务会被归到load的计算中。关于具体怎么样的任务会被归到load的计算中，可以使用manuptime命令看一下Linux对于load的解释：
特别注意，load指的是所有核的平均值，这和cpu的值是有区别的。
还有一个重要的点是，查了资料发现，虽然上面一直强调的是"进程"，但是进程中的线程数也是会被当作不同的进程来计算的，假如一个进程产生1000个线程同时运行，那运行队列的长度就是1000，loadaverage就是1000。
请求数和load的关系
单独的一条线程接到就绪的命令之后，会将命令转给事件分发器，事件分发器根据命令的类型执行对应的命令处理逻辑。由于只有一条线程，只要后面排队的命令足够多到让这条线程一个接一个不停地处理命令，那么load表现就等于1。
举个例子，假设一个服务中有一个线程池，线程池中线程数量固定为64：
因此，总而言之，搞清楚load值和请求数、线程数的关系非常重要，想清楚这些才能正确地进行下一步的工作。
load高、cpu高的问题排查思路
首先抛出一个观点：cpu高不是问题，由cpu高引起的load高才是问题，load是判断系统能力指标的依据。
为什么这么说呢，以单核cpu为例，当我们日常cpu在20%、30%的时候其实对cpu资源是浪费的，这意味着绝大多数时候cpu并没有在做事，理论上来说一个系统极限cpu利用率可以达到100%，这意味着cpu完全被利用起来了处理计算密集型任务，例如for循环、md5加密、new对象等等。但是实际不可能出现这种情况，因为应用程序中不消耗cpu的IO不存在是几乎不可能的，例如读取数据库或者读取文件，因此cpu不是越高越好，通常75%是一个需要引起警戒的经验值。
注意前面提到的是"引起警戒"，意味着cpu高不一定是问题，但是需要去看一下，尤其是日常的时候，因为通常日常流量不大，cpu是不可能打到这么高的。如果只是普通的代码中确实在处理正常业务那没问题，如果代码里面出现了死循环（例如JDK1.7中经典的HashMap扩容引发的死循环问题），那么几条线程一直占着cpu，最后就会造成load的增高。
在一个Java应用中，排查cpu高的思路通常比较简单，有比较固定的做法：
另外，cpu高的情况还有一种可能的原因，假如一个4核cpu的服务器我们看到总的cpu达到了100%+，按1之后观察每个cpu的us，只有一个达到了90%+，其他都在1%左右（下图只是演示top按1之后的效果并非真实场景）：
这种情况下可以重点考虑是不是频繁FullGC引起的。因为我们知道FullGC的时候会有StopTheWorld这个动作，多核cpu的服务器，除了GC线程外，在StopTheWorld的时候都是会挂起的，直到StopTheWorld结束。以几种老年代垃圾收集器为例：
无论如何，当真正发生StopTheWorld的时候，就会出现GC线程在占用cpu工作而其他线程挂起的情况，自然表现也就为某个cpu的us很高而且他cpu的us很低。
针对FullGC的问题，排查思路通常为：
那么频繁FullGC之后最终会导致load如何变化呢？这个我没有验证过和看过具体数据，只是通过理论分析，如果所有线程都是空闲的，只有GC线程在一直做FullGC，那么load最后会趋近于1。但是实际不可能，因为如果没有其他线程在运行，怎么可能导致频繁FullGC呢。所以，在其他线程处理任务的情况下StopTheWorld之后，cpu挂起，任务得不到处理，更大可能的是load会一直升高。
最后顺便提一句，前面一直在讲FullGC，频繁的YoungGC也是会导致load升高的，之前看到过的一个案例是，Object转xml，xml转Object，代码中每处都newXStream()去进行xml序列化与反序列化，回收速度跟不上new的速度，YoungGC次数陡增。
load高、cpu低的问题排查思路
关于load的部分，我们可以看到会导致load高的几个因素：
既然cpu不高，load高，那么线程要么在进行io要么在等待使用cpu。不过对于后者"等待使用cpu"我这里存疑，比如线程池里面10个线程，任务来的很慢，每次只会用到1个线程，那么9个线程都是在等待使用cpu，但是这9个线程明显是不会占据系统资源的，因此我认为自然也不会消耗cpu，所以这个点不考虑。
因此，在cpu不高的情况下假如load高，大概率io高才是罪魁祸首，它导致的是任务一直在跑，迟迟处理不完，线程无法回归线程池中。首先简单讲讲磁盘io，既然wa表示的是磁盘io等待cpu的百分比，那么我们可以看下wa确认下是不是磁盘io导致的：
如果是，那么按照cpu高同样的方式打印一下堆栈，查看文件io的部分进行分析，排查原因，例如是不是多线程都在读取本地一个超大的文件到内存。
磁盘io导致的load高，我相信这毕竟是少数，因为Java语言的特点，应用程序更多的高io应当是在处理网络请求，例如：
针对这种情况，我觉得首先我们应该对整个系统架构的依赖比较熟悉，例如我画一个草图：
对依赖方的调用任何一个出现比较高的耗时都会增加自身系统的load，出现load高的建议排查方式为：
如果上面的步骤还是没用或者没有对接口调用做埋点，那么还是万能的打印堆栈吧，连续打印五次十次，看一下每次的堆栈是否大多都指向同一个接口的调用，网络io的话，堆栈的最后几行一般都有atjava.net.SocketInputStream.read(SocketInputStream.java:129)。
Java应用load高的几种原因总结
前面说了这么多，这里总结一下load高常见的、可能的一些原因：
线上遇到问题的时候首先不要慌，因为大部分load高的问题都集中在以上几个点里面，以下分析问题的步骤或许能帮你整理思路：
最后还是不行，当束手无策时，jstack打印堆栈多分析分析吧，或许能灵光一现能找到错误原因。
结语
先有理论，把理论想透了，实战碰到问题的时候才能头脑清楚。
坦白讲，cpu和load高排查是一个很偏实战的事情，这方面我还也有很长一条路需要走，身边在这块经验比我丰富的同事多得很。很多人有问过我，项目比较简单，根本没有这种线上问题需要我去排查怎么办？这个问题只能说，平时多积累、多实战是唯一途径，假如没有实战机会，那么推荐三种方式：
当真的有实战机会来的时候把握住，即使是同事排查的问题，也可以在事后搞清楚问题的来龙去脉，久而久之自然这方面的能力就会提高上去。