第18章 崩溃（18.7）——案例：无规律卡顿【读书笔记】
文章目录
- 第18章 崩溃（18.7）——案例：无规律卡顿【读书笔记】
- 一、“无规律卡顿”到底在折腾什么？
- 二、先确认：是真的“卡”吗？还是网络/应用假象？
- 三、无规律卡顿排查总思路：三大维度
- 四、工具箱：处理“无规律卡顿”必备几件小工具
- 4.1 任务管理器 & 资源监视器：第一现场观察
- 4.2 性能监视器（Perfmon）：长时间记录“尖刺”
- 4.3 高级手段：WPR / WPA（可选进阶）
- 五、常见成因一：周期性高负载任务（杀毒/备份/索引）
- 六、常见成因二：磁盘 I/O 瓶颈与硬件隐患
- 七、常见成因三：驱动、DPC 延迟与硬件中断
- 八、常见成因四：电源管理与 CPU 频率波动
- 九、常见成因五：应用自身逻辑问题（GC、渲染、单线程）
- 十、一个“无规律卡顿”排查模板（可直接落地）
- 十一、我的小结
第18章 崩溃（18.7）——案例：无规律卡顿【读书笔记】
本文是《第18章 崩溃》里的最后一个案例——无规律卡顿 的读书笔记与延伸。
主题很简单也很折磨人：电脑不蓝屏、不报错，就是“偶尔一卡”，但一旦要干活就来一下。
一、“无规律卡顿”到底在折腾什么？
先把现象说人话：
- 鼠标光标偶尔突然停顿半秒一秒；
- 播放视频时不时来一个小“顿挫”；
- 打字、远程桌面、玩游戏都偶尔“卡一下”，但又说不上是彻底卡死；
- 任务管理器一打开，好像一切都恢复正常了……
这类故障最大的问题是：它既不像持续高负载，也不像标准崩溃，更像一种“系统间歇性抽风”。
从排错角度看，“无规律卡顿”有几个特点：
- 不容易复现：你盯着它看，它往往不发作；
- 现象轻微但频繁：每次就卡一小下，但积累起来非常影响体验；
- 日志和事件不明显：很多时候事件查看器里没有直接的 Error 可以对上号。
所以，本案例的目标不是找到某一个神奇按钮，而是搭建一套**系统化排查“间歇性卡顿”**的思路。
我的理解：这一节的价值在于教你如何把“玄学卡顿”拆成“可度量的资源问题、驱动问题、定时任务问题”。
二、先确认：是真的“卡”吗？还是网络/应用假象？
第一步，先搞清楚：卡顿是在“机器层面”，还是只在某个应用/网络里？
你可以这样快速分层：
- 整个系统都卡？
- 鼠标移动不顺滑；
- 桌面切换、打开开始菜单都很慢；
- 说明倾向于系统层面（CPU/磁盘/驱动/电源管理等）。
- 只在某个应用/网络场景卡？
- 只要开某游戏就卡顿；
- 只在远程桌面时卡，本机操作还算顺；
- 有可能是网络延迟/某个程序自身 GC/渲染性能问题。
优先确认“卡顿作用范围”，能让你少走很多弯路——别把网络延迟当成 CPU 问题。
三、无规律卡顿排查总思路：三大维度
这类问题从书里的案例，加上实际经验，可以压缩成三条主线：
- 资源维度：CPU / 内存 / 磁盘 / 网络 是否偶发“尖刺”？
- 驱动与内核维度：DPC、ISR、硬件中断、驱动 bug 是否在搞事？
- 定时任务与后台服务维度：是不是某个定时任务/杀毒/备份周期性“抢资源”？
你可以把它想成这样的思路：
“看得到的卡顿 → 映射成看得见的数据尖刺 → 再顺着尖刺找到元凶进程/驱动/任务”。
四、工具箱：处理“无规律卡顿”必备几件小工具
4.1 任务管理器 & 资源监视器：第一现场观察
虽然简单，但别小看它们：
- 任务管理器（Ctrl+Shift+Esc）
- 资源监视器（运行中输入
resmon）
关注几个典型指标：
- CPU：是否有某进程周期性冲到 80%+；
- 磁盘：是否有磁盘活动队列长时间 > 1，或者磁盘一直 100%；
- 内存：是否存在频繁分页（硬缺页）；
- 网络：是否有定时占满带宽的进程。
可以在资源监视器里观察一段时间，重点看卡顿前后 10 秒有没有显著“尖刺”。
很多“无规律卡顿”其实是“某个后台程序每隔几分钟扫一次磁盘”“杀毒每隔一会儿扫一波”，数据曲线上一定能看到痕迹。
4.2 性能监视器（Perfmon）：长时间记录“尖刺”
如果卡顿并不频繁，仅凭肉眼盯着任务管理器很难抓到，你就需要让工具帮你长期录制。
打开性能监视器：
perfmon
步骤示意：
- 创建一个“数据收集器集”（Data Collector Set）；
- 添加如下计数器（示例）：
- 处理器 → % Processor Time（总 + 按进程）
- 物理磁盘 → Avg. Disk Queue Length / % Disk Time
- 内存 → Pages/sec
- 网络接口 → Bytes Total/sec
- 设置采样间隔（比如 1 秒）；
- 让它运行一段时间，等用户反馈“刚刚又卡了一下”，再停。
这样你就能从日志中对应时间点找到：
“用户说卡”的那一刻，系统到底发生了什么尖刺，是 CPU、I/O、分页，还是网络。
4.3 高级手段：WPR / WPA（可选进阶）
书里会提到或暗示类似思路：想真正搞清楚“卡顿时到底是谁在占 CPU / 阻塞线程”，可以用 ETW 跟踪工具，例如：
- WPR（Windows Performance Recorder）
- WPA（Windows Performance Analyzer）
命令示意（只做概念记忆）：
# 以管理员身份打开命令提示符
wpr -start generalprofile
# 等待卡顿发生后
wpr -stop C:Temptrace.etl
然后用 WPA 打开 trace.etl，在时间轴上找到卡顿时刻，对应查看 CPU 使用、磁盘 I/O、DPC/ISR 延迟。
这类工具非常适合那种“肉眼完全看不到规律”的卡顿，把问题转换为可以在时间轴上解剖的事实。
五、常见成因一：周期性高负载任务（杀毒/备份/索引）
最常见也最“冤”的一个锅：后台安全工具或维护任务。
典型元凶：
- 杀毒软件定时扫描（全盘 / 核心目录）；
- 系统索引服务（搜索索引重建）；
- 备份软件 / 云同步客户端；
- 日志采集、监控代理（疯狂写/读日志）。
表现为：
- 每隔几分钟、几小时出现一次 CPU 或磁盘突刺；
- 用户只感知到：系统突然一顿，然后又好了；
- 任务管理器中偶尔能看到“某安全进程”冲到顶。
解决思路：
- 在资源监视器/Perfmon 中确认是否是某个特定进程周期性高负载；
- 打开该软件的设置界面，检查：
- 定时任务是否设在工作时间；
- 扫描范围是否过于宽泛（全盘 + 压缩包 + 网络盘）；
- 和安全/运维团队协调：
- 把重负载任务安排在夜间；
- 给业务机器设置合理白名单和扫描策略。
一句话：不要让“为了安全”变成“所有人都实时卡顿”。
六、常见成因二：磁盘 I/O 瓶颈与硬件隐患
如果在卡顿时发现 磁盘活动 100%、队列长度很高，那八成是 I/O 拖累。
常见情况：
- 机械硬盘（HDD）同时承载系统、应用、大量日志/备份写入；
- 某些应用设计不当，频繁小块同步写入；
- 磁盘健康状态不佳（大量重试、坏道前兆）；
- 虚拟机 / 容器环境里多台虚机抢同一物理盘。
排查要点：
- 在资源监视器 → 磁盘页签中看：
- 哪个进程在做大量读写；
- 哪个文件路径被频繁访问；
- 使用磁盘检测工具（如
chkdsk、SMART 工具）检查健康情况。
示例命令：
chkdsk C:
缓解思路：
- 将日志、备份、数据库等高 I/O 任务分散到不同磁盘/分区；
- 尽量为系统和关键应用使用 SSD；
- 对存在硬件隐患的磁盘及时更换。
很多“偶发卡顿”本质上就是：磁盘在背后用力冒汗，CPU 在前面假装没事。
七、常见成因三：驱动、DPC 延迟与硬件中断
有些卡顿属于**“鼠标一顿、声音一抖、画面一僵”**，时间很短但非常频繁，这类往往要怀疑：
- 网卡驱动；
- 声卡驱动；
- 显卡驱动；
- 以及第三方硬件控制软件。
这些驱动可能在内核里做了大量 DPC（延迟过程调用）或 ISR（中断服务），导致：
- 某一瞬间 CPU 被占用处理中断；
- 用户层应用短时间“被饿死”。
这类问题通常需要：
- 用 WPR/WPA 或专业 DPC latency 工具来检测；
- 在时间轴上看到：某个驱动的 DPC/ISR 用时异常。
应对建议：
- 更新到厂商发布的最新稳定版驱动；
- 若是最新驱动出问题，尝试回退到上一个已知稳定版本；
- 在设备管理器中排查是否有黄色叹号或异常设备。
驱动层问题往往是最隐蔽也是最“玄学”的卡顿根源，但一旦用对工具，就会在 DPC/ISR 时间线里“现形”。
八、常见成因四：电源管理与 CPU 频率波动
还有一类比较阴间的卡顿来自：
- 过于激进的电源管理策略；
- CPU 频率经常性大幅度升降；
- 某些笔记本在省电模式下疯狂降频。
表现为：
- 在“高性能”模式下好很多；
- 一旦切回“平衡/节能”模式，操作经常轻微卡顿；
- CPU 使用率并不高，但频率经常压到比较低。
排查方式：
- 在“电源选项”中查看当前计划；
- 使用任务管理器/第三方工具观察 CPU 实时频率。
可尝试：
- 临时切换到“高性能”或自定义“接近高性能”的计划；
- 在 BIOS 中关闭过于激进的节能特性（需谨慎，注意散热）。
有时候机器不是“忙不过来”，而是被你（或厂商）“限制发挥了”。
九、常见成因五：应用自身逻辑问题（GC、渲染、单线程）
最后，不要忘记最朴素的一种可能：应用自己写得一般。
场景包括：
- 单线程 UI 程序在主线程上做大量计算或 I/O；
- 某些语言运行时（比如带 GC 的）周期性做垃圾回收，造成停顿；
- 游戏或图形程序在渲染线程内做了不该做的重活。
判断方式：
- 只要该应用打开，卡顿就频繁；
- 关闭该应用后，系统整体明显顺滑；
- Perfmon/WPR 显示该应用进程在卡顿时 CPU 占用明显尖刺。
这种情况下：
- 从系统层面只能“缓解”（比如提升硬件、调整调度优先级）；
- 从根本上需要应用开发团队优化代码：
- 把耗时操作放到后台线程；
- 优化 GC 参数或减少大对象频繁分配；
- 减少 UI 主线程阻塞调用。
系统调优可以帮应用“撑一阵”，但写得烂的程序，迟早得回到源头重构。
十、一个“无规律卡顿”排查模板（可直接落地）
整理成表格，方便你以后复用：
| 步骤 | 目标 | 操作要点 |
|---|---|---|
| 1 | 确认范围 | 全局卡顿 vs 单应用 vs 网络；先缩小范围 |
| 2 | 抓“尖刺” | 用资源监视器、Perfmon 记录 CPU/磁盘/内存/网络曲线 |
| 3 | 定位主元凶 | 找出在卡顿时刻资源突刺的进程/驱动 |
| 4 | 分类处理 | 后台任务/杀毒 → 调整策略；磁盘瓶颈 → 检查 I/O & 健康；驱动 → 升级/回退；电源 → 调整节能策略；应用 → 找开发优化 |
| 5 | 验证 & 复盘 | 改完之后再观察一段时间，确认卡顿频率下降；把结论写入知识库 |
排查“无规律卡顿”的关键不是某个神奇指令，而是这套“观察 → 记录 → 对齐时间 → 对应资源尖刺 → 分类处理”的思维链。
十一、我的小结
- “无规律卡顿”表面上是玄学，实质上是各种周期性负载、驱动延迟、硬件瓶颈、应用逻辑问题叠加出来的结果。
- 只要你愿意把“用户感受到的那一顿”对齐到具体的时间戳，再用工具去看那一刻系统在干嘛，卡顿就会从“玄学”变成“可以解释的物理现象”。
- 这一节和 18 章前面的所有案例合在一起，其实构成了一套通用的“崩溃与卡顿排错方法论”，非常适合整理成自己的团队教材或内部知识库。
到这里，第 18 章的案例就串完了：从错误信息、崩溃、升级失败，到转储丢失和无规律卡顿，你已经有了一整套从 日志 → Dump → 资源监控 → 驱动分析 → 策略调整 的完整排查工具链。
