内核态CPU使用率（sy）持续偏高需排查系统调用、中断、锁及内核路径：先确认是否真实异常（sy>25%且持续数分钟），排除容器cgroup干扰；用mpstat、vmstat分析CPU不均衡与上下文切换；perf定位热点函数如do_syscall_64、futex_wait_queue_me；strace检查高频低效syscall；结合dmesg、/proc/interrupts等查页回收、中断绑定、驱动异常。
内核态 CPU 使用率（sy）持续偏高，说明问题不在应用代码本身，而在进程与内核的交互层。这时候不能只盯着 Java 堆栈或业务日志，得转向系统调用、中断、锁和内核路径本身。
先确认 sy 高是否真实异常
不是所有 sy 高都代表故障：短时 spike（如批量创建线程、突发网络包处理）属正常；但若 sy > 25% 且稳定维持数分钟以上，就该深入了。注意排除干扰：
- 检查是否运行在容器中——cgroup 的 CPU quota 限制会导致 top 显示 sy 偏高，实际是调度等待
- 用
mpstat -P ALL 1观察各 CPU 核的 %sys 是否不均衡，若集中在某几个核，可能和中断绑定或软中断分布有关 - 对比
vmstat 1中的cs（上下文切换）和in（中断次数）：cs > 10k/s 或 in > 5k/s 且同步升高，大概率指向高频切换或中断风暴
定位内核侧热点函数
核心工具是 perf，它能采样到内核符号级的执行热点：
- 快速看全局热点：
perf top -p [pid] --call-graph dwarf（针对单进程）或perf top -g（全系统），重点关注do_syscall_64、entry_SYSCALL_64、futex_wait_queue_me、tcp_v4_do_rcv等入口函数 - 录制火焰图更直观：
perf record -g -a -- sleep 30，再用perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > kernel-flame.svg - 若发现大量
__softirqentry_text_start下的net_rx_action或timer_interrupt，说明软中断处理过载，需查网卡 RSS 配置或定时器精度设置
抓系统调用行为特征
sy 高往往对应高频、低效的系统调用，strace 是直击要害的手段：
- 对目标进程做调用统计：
strace -p [pid] -c -f -e trace=%all 2>&1 | head -20，重点关注read/write调用次数、平均耗时，以及futex、epoll_wait、clock_gettime是否出现“毫秒级高频触发” - 若看到大量
futex(FUTEX_WAIT_PRIVATE, ...)返回 -1 EAGAIN，说明存在激烈锁竞争；若epoll_wait总是返回 0 或极小事件数，可能是空轮询 - 留意是否有监控 agent（如某些 Java Agent、eBPF 探针）注入了过多
syscall拦截点，它们会把每次方法进出都转成内核态切换
排查内核机制与配置偏差
有些 sy 高源于内核子系统本身的策略或资源紧张：
-
页回收压力大：dmesg 中搜
page reclaim或low memory，结合cat /proc/vmstat | grep pgpgin\|pgpgout\|pgmajfault看换页频率；内存不足时内核频繁扫描 LRU 链表，推高 sy -
中断未均衡：用
cat /proc/interrupts查看网卡、NVMe 等设备中断是否全部落到少数 CPU 上；配合irqbalance --debug或手动绑核（echo $mask > /proc/irq/*/smp_affinity）验证改善效果 -
内核模块或驱动异常：
dmesg -T | tail -50扫描 WARN/BUG 日志；特别关注第三方驱动（如 GPU、RDMA）、旧版内核补丁引发的自旋锁死循环
