容器CPU飙升需分层排查：先用docker stats确认是否持续>80%超5分钟，再结合宿主机top区分是容器、dockerd还是系统进程；进容器用top-H查线程，Java用jstack定位nid，Go用pprof，通用进程用strace；检查cpu.stat中nr_throttled>0判断节流；同步排查内存压力、上下文切换>10000/s、I/O等待及Docker事件。
容器 CPU 使用率飙升，不能只看 top 里哪个进程占得高，得顺着资源控制链一层层查——从容器外到容器内、从系统级到应用线程级、从配置到行为。
先确认是不是真“飙”了
用 docker stats 看实时使用率，注意持续时间：单次峰值不等于问题，连续 3～5 分钟 >80% 才算异常。同时对比宿主机 top，确认是某个容器独占 CPU，还是 Docker daemon 或其他系统进程在吃资源。如果 dockerd 自身 CPU 高，可能是镜像拉取频繁、守护进程 bug 或日志驱动阻塞。
进容器查具体进程和线程
找到高负载容器后，执行：
- docker exec -it <container_id> sh 进入容器
- 运行 top -c 或 htop（如已安装），按 %CPU 排序，记下 PID
- 对 Java 进程：用 top -H -p <pid> 查线程级占用，把高 CPU 的 TID 转成十六进制（printf "%x\n" <tid>），再用 jstack <pid> | grep -A 20 "nid=0x..." 定位到具体方法栈
- 对 Go 进程：访问 /debug/pprof/profile 抓取 CPU profile，用 pprof 分析热点函数
- 对通用进程：用 strace -p <pid> -e trace=clone,execve,futex 观察是否卡在系统调用或锁上
检查 cgroups 是否在节流
CPU 使用率显示 100%，但业务变慢，很可能是被内核限流了。查节流指标：
- cat /sys/fs/cgroup/cpu/docker/<container_id>/cpu.stat | grep throttled —— 关注 nr_throttled 和 throttled_time
- 若 nr_throttled > 0，说明容器已超出 --cpus 或 --cpu-quota 设置，被强制暂停调度
- 对比启动参数：docker inspect <container_id> | jq '.HostConfig.CpuCount, .HostConfig.CpuQuota, .HostConfig.CpuPeriod'
关联看其他压力信号
CPU 飙升常是结果，不是原因。同步排查：
- 内存压力：容器内存接近 limit？cat /sys/fs/cgroup/memory/docker/<id>/memory.usage_in_bytes 对比 memory.limit_in_bytes；若有 swap 或大量 page faults，GC 或缺页中断会拖累 CPU
- 上下文切换：宿主机跑 pidstat -w 1，若每秒上下文切换 >10000，可能是线程/协程过多或锁竞争激烈
- I/O 等待：iostat -x 1 看 %util 和 await；iotop 看进程实际读写量；D 状态进程多，说明卡在磁盘或网络设备
- Docker 事件：docker events --filter type=container --since 1h 查是否有频繁 restart、OOM kill 或 health check 失败
