企业官网建设流程全解析

运维这行干久了，半夜被报警电话叫醒几乎成了肌肉记忆。前几天凌晨两点多，线上某核心服务CPU直接拉满100%，接口超时率从0.1%飙到30%，用户侧已经出现明显卡顿。我一边开电脑一边在脑子里过了一遍排查流程，最终从接到报警到定位到具体代码行，用了大概二十分钟。这篇文章就把我这些年处理线上CPU 100%问题的完整思路、命令细节和踩坑记录整理出来，希望能帮你少走点弯路。

这个问题本身不复杂，但很多人栽在第一步——不知道该看什么、先做什么、哪些数据必须在现场保留下来。CPU 100%不像内存泄漏那样有渐进过程，它往往是突发性的，服务器一旦被打满，现场转瞬即逝，进程可能被OOM Killer干掉，线程栈可能已经被回收。所以这篇文章的核心就三件事：怎么快速定位到进程，怎么从线程栈里找到问题代码，怎么在事后复盘出真正的根因。适合刚接触线上问题排查的后端开发、运维和SRE同学，也适合那些已经写过不少代码、但还没完整处理过一次CPU危机的朋友。

1. 线上CPU 100%：先分清是真的忙还是在空转

1.1 第一件事不是翻代码，而是确认“忙”的形态

接到报警后，我见过太多人第一反应是打开IDE翻业务代码，试图从逻辑上推理哪里可能死循环。这个方向本身没错，但顺序反了。CPU 100%分两种截然不同的形态：一种是真的在拼命执行指令，比如死循环、密集计算；另一种是CPU在空转，比如自旋锁等待、线程频繁切换、内核态异常。这两种形态的排查路径完全不同，前者要看用户态CPU占比，后者要关注系统态CPU和上下文切换。如果上来就翻代码，很可能被业务逻辑带偏，绕半天发现根本不是那行代码的问题。

正确的第一步是登上服务器，用top命令看一眼全局。这一步的目的不是定位，而是确认三件事：CPU是单核满还是多核满，用户态和系统态的占比分别是多少，load average的走势是什么样的。单核满和多核满指向的问题类型完全不一样，单核满往往是某个单线程任务卡死，多核满则更可能是多个线程同时陷入循环，或者是大量线程在竞争锁。

1.2 五个关键指标，决定排查方向

top命令第一屏会输出大量数据，但真正需要关注的只有五个：

这里有个容易忽略的细节：如果wa占比很高，CPU 100%可能是个假象。前几天我还遇到一个案例，MySQL所在物理机的CPU显示满了，但us和sy都不高，wa占了80%以上，实际上是某个慢查询在疯狂扫表，把磁盘IO打爆了，CPU全在等IO。这种情况往代码死循环的方向查就完全跑偏了，得先看SQL、看磁盘队列。

确认了"忙"的形态之后，再往下走才有意义。us高就走用户态分析路线，sy高就要多关注线程切换和系统调用，wa高则先去查IO链路。记住这个分流逻辑，能省下至少半小时的无效排查时间。

2. 五分钟锁定进程：从top到pidstat

2.1 top命令的正确解读姿势

top进入交互界面后，第一件事是按一下大写的P，让进程列表按CPU使用率排序。这一步很基础，但有个细节值得说：top默认显示的是累计CPU使用率的某种快照，单次刷新可能不够准确，建议多按几次空格键强制刷新，或者直接看"top -n1 -b"这种批处理模式的输出，避免动态刷新带来的读数跳动。

看进程列表时，锁定那个CPU占用最高的PID。但千万别只盯着第一行，因为线上服务往往是多进程多线程架构，有时候罪魁祸首不在最顶上，而是在前五名里。我习惯把前十个CPU占用高的进程都记下来，连同PID、PPID、进程名一起，一并保存到本地日志文件里。现场数据是排查问题的唯一凭据，服务器重启之后什么都没了。

这里还要提醒一点：记下来的不光是进程名，最好连启动时间也记。有一次我排查了一个多小时，最后发现CPU 100%的进程根本不是我们的Java服务，而是某个定时任务脚本fork出来的僵尸进程。如果一开始就从进程名上"先入为主"，很容易忽略掉这种非预期进程。

2.2 用pidstat记录现场，避免对着动态数字瞎猜

top是动态刷新的，光靠肉眼盯着一闪而过的数字，很难判断CPU占用是持续性的还是瞬时尖峰。这时候pidstat就派上用场了。pidstat是sysstat工具包里的命令，专门用来按进程或线程维度统计资源使用情况，比top更适合做长时间采样。

pidstat -p 12345 -t 1 10

这条命令的意思是对PID 12345这个进程，按线程维度（-t）每秒采样一次，连续采样10次。输出里能看到每个线程的CPU占用率，而且采样是定时的，能把"哪个线程在持续吃CPU"这个事实稳定地记录下来。如果某个线程的CPU占用率始终在90%以上，那就说明问题基本锁定了；如果所有线程的CPU占用率都不高，但进程整体CPU很高，那就要考虑是不是GC线程、编译线程或者内核态开销。

采样数据一定要重定向到文件里存下来：

pidstat -p 12345 -t 1 30 > /tmp/cpu_issue_pidstat.log 2>&1

别嫌这个动作多余，事后复盘的时候，这份采样日志就是铁证。领导问起来、或者周会上要写事故报告，没有当时的现场数据，全靠回忆口述，那叫"讲故事"，有了这份日志，那叫"证据链"。

2.3 确认进程之后先别急着kill

很多人一看到CPU 100%的进程，手比脑子快，直接kill -9。这是线上运维的大忌。kill之前必须想清楚三件事：这个进程是不是有状态的节点，比如正在处理消息队列里的任务；这个进程是不是集群里的唯一副本，杀掉之后流量往哪切；现场数据是不是已经保存完整了，线程栈抓了没，网络连接状态看了没。

我处理过一起事故，同事看到某个消费者进程CPU飙高，果断kill掉，以为是它在作妖。结果这个进程是消息队列的唯一消费者，kill之后消息开始积压，下游系统陆续报警，最后又是一轮新的排查。CPU 100%的进程往往只是"受害者"，真正的病根可能在它调用的下游服务、它访问的数据库或者它持有的某个共享资源。进程本身只是暴露问题的载体，不是问题本身。

正确的顺序应该是：先抓线程栈、看网络连接、查日志，把能收集的证据都收集完，再决定是重启还是保留现场。如果必须止损，我通常会先尝试让进程load降下来的操作，比如限流、摘流量、暂停某个线程，最后才考虑重启。

3. 深入线程内部：从jstack到perf

3.1 把线程ID换算成十六进制，再抓jstack

进程锁定了，下一步就是把范围从进程缩小到线程。以Java服务为例，最经典的组合拳是top -H加jstack。

先用top -Hp拿到进程内所有线程的CPU占用率，找到那个最耗CPU的线程，记下它的PID（注意，这里是线程ID）。jstack的输出里，线程信息是以十六进制显示的，所以需要先把十进制线程ID换算成十六进制：

printf '%x\n' 34567

得到十六进制值之后，执行线程栈抓取：

jstack -l 12345 > /tmp/jstack.log 2>&1

然后在线程栈文件里搜索这个十六进制线程ID，就能看到它当时在干什么。这里有个很关键的实操细节：jstack抓取和top -H采样之间要尽可能快，最好在几秒内完成。线程栈是瞬态快照，错过了就误判了。如果是持续性CPU飙高，多抓几次jstack，间隔两三秒抓一次，连续抓三五份。单份线程栈可能恰好落在某个线程的休眠状态，看不出问题，但多份对比就能看出哪些线程始终在活跃运行、卡在什么调用栈上。

另外，jstack不是银弹。它只能看到JVM管理的线程，对于JVM自身的一些线程（比如GC线程、JIT编译线程）也能看到，但看不到内核态的系统调用耗时。如果jstack里看不出明显的热点，别急着下结论，可能问题根本不在Java业务代码里。

3.2 jstack输出怎么读：找状态，找调用栈，找特征

jstack输出很长，新手上手容易看花眼。我的读法分三步：

第一步，先看全局线程状态分布。Java线程常见的状态有RUNNABLE、WAITING、TIMED_WAITING、BLOCKED。CPU 100%的场景里，大量线程处于BLOCKED状态往往说明锁竞争严重，大量线程处于RUNNABLE但干着无关紧要的事，说明可能有隐性的忙循环。

第二步，定位到之前换算出来的十六进制线程ID，看它的线程栈。重点关注栈顶几行，也就是正在执行的方法。如果栈顶是JDK的类库方法，比如java.util.HashMap的扩容、java.util.regex的匹配，别急着往业务代码想，先用jstack -l再确认一下是否有锁信息。

第三步，多份jstack做对比。如果每隔三秒抓一次，连续抓了五次，每次那个高CPU线程都在同一个方法里，而且栈几乎不变，那基本就是死循环或者长时间阻塞性的自旋。如果栈在变，但始终在同一个类库的不同方法间跳转，可能是某种并发组件在做大量重试。

这里多说一句，很多人忽略了jstack里的"Found one Java-level deadlock"提示。虽然CPU 100%不一定是死锁，但死锁伴随大量线程blocked时，CPU也可能被撑高。看到这个提示一定要细看是哪些线程、持有哪些锁、等待哪些锁。

3.3 非Java场景：perf top和strace交叉定位

Java场景有jstack这个神器，但线上还有大量非Java服务，比如Go、C++、Node.js，或者压根就是个老旧的shell脚本在被反复执行。这些场景下我习惯用perf top来定位热点函数。

perf top -p 12345

perf top会实时显示进程内CPU采样最密集的函数符号。如果符号是16进制地址而不是可读的函数名，说明进程的符号表没加载或者被strip了，这时候可以尝试用perf record配合perf report做离线分析，或者临时装一下debug symbol包。对于Go服务，pkill -QUIT拿到goroutine栈，或者用Go自带的pprof接口，比perf更直接。

strace是另一个补充手段。如果怀疑进程在疯狂做系统调用（文件读写、网络请求、锁操作），可以这样：

strace -p 12345 -c -f -t -o /tmp/strace.log

-c参数会在结束时汇总各类系统调用的次数和耗时，-f会跟踪子线程，-t记录时间戳。跑个十几秒到几十秒，Ctrl+C结束，看统计结果里哪类系统调用最多。之前遇到过一个诡异案例，Java进程CPU很高但jstack完全正常，后来strace一看，进程在疯狂执行futex系统调用，是JVM内部的线程同步在做无意义的自旋，最后定位到是Linux内核版本和JVM版本的一个已知兼容性问题。

4. 根因分析：什么样的代码会把CPU打满

4.1 业务死循环与正则灾难

找到线程栈之后，接下来的工作就是解读线程栈，判断根因。最常见的根因之一是业务代码里的死循环。我见过最典型的案例是一个while循环里等待某个状态变更，但状态变更的写入方因为异常提前返回了，这个循环就成了永恒的旋转门。还有一种是for循环里忘记更新循环变量，这个属于低级错误，但线上真的发生过。判断依据就是jstack里栈顶始终在同一个业务方法里，而且多份快照完全一致。

比死循环更隐蔽的是正则表达式的灾难性回溯。Java的java.util.regex和很多语言的默认正则引擎一样，在匹配某些复杂模式时存在指数级回溯的风险。举个例子，一个看似正常的模式在处理异常长的输入时，可能从毫秒级膨胀到分钟级，把CPU直接打满。这种问题在jstack里看，线程栈会卡在java.util.regex.Pattern的匹配方法上，但代码逻辑本身没有"死循环"。排查时看到正则相关栈，不要犹豫，直接把那个正则拿去做正则回溯测试。

顺便说一句，日志框架也有类似问题。有些日志框架在拼接日志消息时会做大量的字符串格式化，如果业务代码把日志开关关掉了但消息参数已经构造完，字符串拼接的开销一样存在。这就是为什么定期清理不用的DEBUG日志、用参数化占位符代替字符串拼接，不光是代码洁癖，更是线上性能的保命符。

4.2 频繁GC与内存分配压力

Java服务和多数带垃圾回收机制的运行时，CPU 100%的另一大来源是GC。这里的逻辑很多人搞反了：以为GC是内存问题，其实GC爆掉时CPU一样会被打满。频繁Full GC会让所有业务线程停顿，CPU看着就很忙，但业务线程几乎没进展。

判断GC问题的标准姿势是用jstat看GC状态：

jstat -gcutil 12345 1000 10

每一秒输出一次，连续十次，看YGC和FGC的频次以及耗时。如果FGC次数飞速上涨，或者每次FGC耗时都在几百毫秒以上，那基本可以断定是GC风暴。接下来用jmap导出堆dump：

jmap -dump:live,format=b,file=/tmp/heap.hprof 12345

然后用MAT或者VisualVM分析大对象、重复对象、以及存活对象的分布。GC风暴的根因通常是这几种：内存泄漏导致堆持续增长、大对象直接进了老年代、或者某个缓存组件无节制地扩张。定位到大对象之后再看业务代码是哪个环节创建了它。

这里要强调一个操作顺序：先抓jstack，再抓jmap dump，最后再考虑重启。因为jmap dump时进程会暂停一段时间，线上高峰期慎用。如果服务比较重要，先在低峰期操作，或者用带live参数的dump方式减少停顿。实在没法dump的话，至少把GC日志找出来，很多情况下GC日志里的信息已经足够定位了。

4.3 锁竞争与线程上下文切换

锁竞争导致CPU飙升这事，经常被误判成业务代码繁忙。大量线程在抢占同一个锁时，线程会反复进入阻塞和唤醒状态，这个过程中线程上下文切换的开销非常大。Linux里每个线程切换都要几百纳秒到几微秒，如果每秒切换几十万次，CPU就全耗在这上面了。

检查方法有两个：一是vmstat看cs列（上下文切换次数），正常服务器每秒几千次，异常时可以到几十万甚至上百万次；二是看jstack里大量线程处于BLOCKED状态，并且它们等待的锁是同一个。定位到锁之后，去分析为什么那么多线程在抢同一个锁——是锁的粒度太大，比如把大段业务逻辑都包在synchronized里；是锁的持有时间太长，比如持锁期间调用了外部接口；还是锁的数量太少，比如连接池只有10个但并发有500。

synchronized之外，显式锁比如ReentrantLock、StampedLock，还有并发工具类里的自旋（比如AtomicLong的CAS重试），也可能造成空转。虽然Java的CAS不是无限制自旋，但高并发下大量的CAS失败重试仍然会消耗不少CPU。这种问题在jstack里常常表现为线程处于RUNNABLE状态，栈顶是Unsafe.compareAndSwapInt这类方法。

4.4 外部依赖超时与重试放大效应

最后一种高频根因，我把它叫做"多米诺型CPU飙升"。业务代码本身没毛病，但它调用的外部依赖（HTTP接口、数据库、Redis）超时了，于是业务代码进入重试逻辑。重试本身没问题，但如果重试的退避策略太激进、超时时间设置得太长，失败请求会在短时间内指数级放大，CPU和线程池都被堆积的任务打满。

举个例子：一个接口正常响应20ms，下游Redis挂了一半节点，每次访问卡住2秒才超时。原本每秒能处理5000个请求的线程池，现在每个线程要等2秒才能完成一次任务，线程池很快被占满，队列开始积压，调度器忙着把积压的任务分配给CPU，CPU使用率直线上升。这种情况下，jstack里你会看到大量线程阻塞在SocketInputStream.read或者类似的地方，这不是死循环，而是等待IO超时。

排查这类问题的关键在链路追踪。如果有SkyWalking或Zipkin之类的工具，直接看调用链上哪些外部调用耗时异常；如果没有，就去查数据库慢查询日志、Redis的慢日志、以及上游服务的响应时间监控。找到超时点之后，修正超时配置和重试策略才是真正的解药，只盯着本服务的代码改来改去，问题永远不会消失。

5. 实战复盘：三个真实案例拆解

5.1 案例一：日志框架引发的"死循环"疑云

那是个Spring Boot服务，某个接口的TPS从峰值直接跌到接近0，CPU从20%跳到了100%，而且us占比极高。jstack抓下来，一看栈顶全是一个自定义的日期格式化方法，肉眼看上去就是死循环。但代码翻了三遍，逻辑完全正常，没有循环，没有递归。后来用jstack多抓了几份，发现线程栈在同一个方法附近微妙地变化，而且大量时间花在SimpleDateFormat的format上。

真正的问题在于：这个接口每处理一个请求都要格式化一个日期，而SimpleDateFormat是线程不安全的。为了避免线程安全问题，有人在外层用ThreadLocal做隔离，每次请求都创建新的SimpleDateFormat对象，然后在高并发下变成一场频繁的短生命周期对象创建风暴。对象创建本身不可怕，可怕的是每个SimpleDateFormat内部都会做模式解析，这个解析过程的CPU开销被成百上千倍的并发放大。解决方案很简单：把日期格式定义成静态常量，配合线程安全的DateTimeFormatter来使用，或者用Apache Commons Lang的FastDateFormat。CPU占用当天就从100%降到了15%。这个案例告诉我一个道理：CPU 100%的热点代码行不一定是"死循环"，也可能是大量线程都在执行一段本不该重复执行的初始化逻辑。

5.2 案例二：Jackson序列化大对象引发的GC风暴

另一回，一个消息推送服务突然CPU飙升，报警显示FGC频繁，大概每两秒一次Full GC，每次耗时600毫秒以上。先抓了jstack，发现业务线程大多在ObjectMapper.writeValueAsString的方法上。再看jstat，老年代占用率一直徘徊在95%以上。

当时的场景是：业务侧把一个大订单对象放进了缓存，然后每次推送消息时从缓存里取出来，用Jackson序列化成JSON再发出去。问题出在两个地方：一是这个大对象里嵌套了一个list集合，这个集合因为历史原因越攒越大，达到了几万个元素；二是缓存的时间设置过长，这个对象在缓存里待了半小时，期间list还在不停增长。每次序列化都要遍历整个list，分配大量临时对象，年轻代装不下，全挤进老年代，老年代很快被打满，于是触发频繁Full GC。

处理方式是三层动作：第一，立刻止损，清掉这个缓存key，CPU在几分钟内就回落了；第二，临时改配置，把消息推送的序列化改为异步线程池，避免阻塞业务线程；第三，长期修复，给缓存里的对象加了大小上限，超过阈值就截断，同时把缓存过期时间缩短到五分钟。全程下来，GC恢复到每十分钟一次Full GC的正常水平。

5.3 案例三：连接池超时与重试的放大效应

第三个案例是个典型的"外部依赖拖垮主服务"。一个订单中心的接口CPU持续偏高，但jstack里没有明显的死循环，也没有GC问题，线程大量阻塞在MySQL查询上。当时第一反应是慢SQL，查了慢查询日志，确实有几条SQL扫描行数过亿，但它们的执行频率并不高，不足以解释CPU 100%。

继续看线程栈，发现大多数线程阻塞在获取数据库连接的环节，也就是等待连接池分配连接。进一步查连接池状态，最大连接数是50，但活跃连接数已经打满，线程都在排队。为什么活跃连接打满？因为那几条慢SQL每一条执行耗时都在十几秒，把连接占着不放。一个慢执行的连接占满一个池子里的名额，其他正常请求拿不到连接，就阻塞等待。而阻塞等待本身不产生太多CPU，但业务侧的调用方还配置了超时重试，超时后重试的请求又涌进来，排队线程数量暴增，调度开销和上下文切换把CPU彻底拉满。

这个问题的本质不是SQL本身有多慢，而是慢SQL的隔离性太差。最终解决方案是三条：给慢SQL单独建了一个只读连接池，限制它最多占用几个连接；给连接获取操作加了超时时间，拿不到连接就直接快速失败而不是无限等待；优化那几条慢SQL的索引。三层处理完之后，CPU稳定在20%左右。

6. 排查工具箱与操作禁忌

6.1 一套可以直接抄的排查命令组合

结合前面讲的各种场景，我整理了一套线上CPU 100%的排查命令组合，按顺序执行就行。这套命令我已经用了很多年，实测在绝大多数Linux环境下都能跑通：

# 第一步：全局视角，确认负载与CPU状态 top -n1 -b | head -30 # 第二步：定位高CPU进程，保存现场 top -n1 -b | sort -k9 -r | head -20 > /tmp/cpu_top.log # 第三步：对可疑进程做线程级采样（Java示例） pidstat -p <PID> -t 1 10 > /tmp/cpu_pidstat.log # 第四步：换算线程ID并抓线程栈（Java） printf '%x\n' <线程PID> jstack -l <进程PID> > /tmp/jstack1.log sleep 3 jstack -l <进程PID> > /tmp/jstack2.log # 第五步：检查GC状况（Java） jstat -gcutil <进程PID> 1000 10 # 第六步：用perf看热点函数（通用） perf top -p <进程PID> # 第七步：检查上下文切换与IO等待 vmstat 1 10

这套组合拳跑完，大部分场景都能定位到问题层面。注意每一条命令都要保存输出，别只看不吃，也不要在同一台服务器上同时跑太多重型工具，先top和pidstat，够了再上jmap到堆dump，别一上来就把进程停住。

6.2 三个容易犯的错误，我全踩过

第一个错误是拿生产环境当测试环境乱试工具。jmap dump、重启、甚至升级JDK，这些操作都有副作用，在低峰期操作和高峰期操作完全不是一回事。有一次我在高峰期执行jmap dump，进程STW了将近十秒，线上接口超时瞬间翻倍。之后再遇到类似场景，我都会先跟团队确认能否在低峰期操作，或者确认这个节点是否可以快速摘除流量。

第二个错误是只看一个时间点的快照就下结论。CPU 100%有持续型和尖峰型之分，持续型好办，尖峰型最坑。有些服务的CPU使用率每五分钟就有一个尖峰，持续十几秒又降下去，恰好报警阈值卡在这个尖峰上。这种问题必须靠pidstat这类定时采样工具拉长时间段看趋势，单点top快照完全说明不了问题。

第三个错误是忽略系统层面的告警数据。很多公司有监控系统，比如Prometheus、Zabbix之类的，报警来临时监控面板上已经有不少信息了。但很多开发上了服务器就把监控数据抛在脑后，只顾着敲命令。说句实话，监控面板上的CPU使用率历史曲线、IO等待曲线、网络包量曲线，往往比现场top的输出更有价值。因为它们能告诉你CPU是从哪个时间点开始飙的、和哪个部署行为时间吻合、同时段有没有磁盘或网络异常。

7. 常见问题速查表

最后把这几年遇到的高频问题，按"症状—原因—排查突破口—解决方向"整理成一张表，方便以后遇到问题时快速对照。

排查线上CPU问题，说到底是两件事的博弈：一是抢时间，在信息消失前尽可能留证据；二是讲逻辑，从全局指标分流到进程，再细化到线程和调用栈，最后落到代码和外部依赖上。这中间没有任何一条捷径，但每一步都有章可循。上面这套流程和命令，你在自己的环境里多练几次，等真出事故的时候就不会手忙脚乱了。

我个人最大的体会是，CPU排查最值钱的不是把某个进程杀掉的那一刻，而是把一根完整的证据链保留下来的那几分钟。服务器随时可能重启，监控窗口随时会过期，但只要你留住了现场数据，事后无论做事故复盘、写报告还是设计改进方案，心里都有底。另外一个实用建议：平时在测试环境故意制造几次CPU 100%的故障，比如写个死循环跑起来，然后按这套流程从top到jstack走一遍，练到条件反射为止。线上的每一分钟都很贵，别把第一次完整练习留给生产事故。