排查CPU和内存问题关键在于理清“谁在用、为什么用、能不能少用”三层逻辑：CPU飙高需区分忙（us高）或病（sy/wa高），内存异常要分辨真泄漏与缓存增长，避免被系统缓存误导。

排查 CPU 和内存问题，关键不在工具多不多，而在路径清不清。很多故障反复发生，不是因为没看到现象，而是没理清“谁在用、为什么用、能不能少用”这三层逻辑。下面按实际高频场景分块梳理，不讲理论，只列动作和判断依据。

CPU 飙高：先分清是“忙”还是“病”

用户态（us）持续高于 70%，大概率是应用自身问题；内核态（sy）异常升高，往往指向锁竞争、频繁系统调用或驱动异常；等待 I/O（wa）高，则要查磁盘或网络是否卡住。

• Linux 下用 top → 按 P 排序 → 记下高占用进程 PID，再执行 ps -T -p PID 查具体线程
• Java 进程立刻抓堆栈：jstack PID > jstack.log，重点看 RUNNABLE 状态下重复调用的方法
• 若线程 ID（TID）占 CPU 高，转成十六进制后用 jstack 日志定位对应线程栈，确认是否死循环、无限重试或同步阻塞
• 别一上来就 kill 进程——先确认它是不是批处理任务或定时导出，避免误判为故障

内存异常：区分“用得多”和“收不回”

Windows 任务管理器里“已使用”高≠有问题，“硬错误（Hard Fault/sec）”持续大于 10 才真正危险；Java 应用则要看 GC 频率和老年代占用趋势，不是单看堆内存百分比。

• Java 启动时务必加参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/，OOM 后自动生成分析文件
• 用 MAT 打开 .hprof 文件，优先看 Dominator Tree 和 Leak Suspects 报告，关注 ArrayList、HashMap、未关闭的 InputStream 或静态缓存引用
• Windows 上打开资源监视器（Resource Monitor），切到“内存”页，按“提交(KB)”排序，找出长期不释放、提交量远大于工作集的进程
• 警惕“内存泄漏”伪装成“缓存增长”——比如某服务重启后内存从 1GB 慢慢涨到 4GB 且不回落，基本可锁定

系统级资源错觉：别被任务管理器骗了

Windows 的“已缓存”是预读和 standby 内存，属于良性占用；Linux 的 buff/cache 也是同理。真正该盯的是“可用内存是否持续低于 500MB”或“swap 使用是否增长”。

• Windows 中打开性能监视器（perfmon），添加计数器：Memory\Available MBytes 和 Memory\Pages/sec，后者长期 > 20 就说明内存压力大
• Linux 执行 free -h 时，重点看 available 列，不是 free；vmstat 1 中看 si/so（swap in/out）是否非零
• 禁用 SysMain（Superfetch）和服务 Host Network Service（如果不用远程桌面或网络发现）能立竿见影降低基础内存占用
• Edge/Chrome 多标签页吃内存？试试启用“效率模式”或限制后台标签页刷新，比关进程更治本

避坑清单：那些看似合理实则翻车的操作

很多“优化教程”教人改注册表、删系统服务、强行清空 standby 内存，结果不是蓝屏就是功能异常。以下几条请刻进本能：

• 不要手动运行“内存清理软件”——它们靠触发 EmptyWorkingSet 强制释放缓存，反而打断系统预读逻辑，导致后续操作更卡
• 不要盲目禁用 svchost.exe 下所有服务——有些是 Windows Update、安全中心或打印后台的关键依赖
• JVM 设置 -Xms 和 -Xmx 不建议设为相同值，尤其在容器环境，会剥夺 JVM 动态调整空间的能力
• Windows 11 中禁用 Widgets 或 Copilot 不一定能省多少内存，但关闭“聚焦搜索”和“推荐内容”能减少常驻进程数量