活动监视器无法直接显示内核空间内存泄漏，但可通过内存压力持续偏高、已压缩内存异常增加、kernel_task占用突增等线索间接识别，再结合kextstat、footprint、日志分析及驱动卸载验证锁定泄漏源。

活动监视器本身无法直接显示内核空间内存泄漏，但它能帮你发现线索——当系统整体内存压力持续升高、而用户进程占用并不高时，就该怀疑内核层出了问题，尤其是第三方驱动（如虚拟机、外设驱动、安全软件等）引发的内核扩展（kext）泄漏。

看“内存压力”和“已压缩内存”趋势

打开活动监视器 → 切换到“内存”标签页：

• 重点观察右上角“内存压力”图表：长期处于黄色或红色，且不随应用关闭而回落，说明底层资源未释放
• 留意“已压缩内存”数值是否异常高（例如 >4GB），这常是系统在拼命腾挪空间，掩盖真实泄漏
• 对比“物理内存”总容量与“已使用”栏——若两者接近但“应用程序内存”加起来远小于该值，差额大概率被内核占用了

结合终端命令定位可疑驱动

活动监视器只展示用户态进程，需用命令补全视图：

macOS Automator Services

部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...

下载

• 运行 kextstat | grep -v com.apple：列出所有非苹果签名的内核扩展，重点关注最近安装或更新过的条目（如 parallels、vmware、logitech、rog、cleanmymac 等）
• 配合 sudo footprint -t system -w 10 | grep "Kernel Allocations"：每10秒刷新一次内核内存分配量，持续观察是否稳定上涨
• 若发现某 kext 的 Bundle ID（如 com.parallels.kext.prl_hypervisor）与内存增长节奏吻合，基本可锁定目标

验证驱动卸载后的内存变化

不能仅靠猜测，要实测效果：

• 记下当前内存压力值和 kernel_task 占用内存（可在活动监视器中看到）
• 用 sudo kmutil unload -b [BundleID] 卸载一个可疑驱动（需重启前临时生效，部分需先禁用 SIP）
• 不重启，继续用活动监视器观察 15–30 分钟：若内存压力明显回落、已压缩内存减少、kernel_task 内存下降，则该驱动极可能存在问题
• 逐个测试，避免同时卸载多个，否则无法归因

辅助日志交叉印证

活动监视器看不到的日志，可能藏着关键提示：

• 在终端运行 log show --predicate 'eventMessage contains "zalloc" or eventMessage contains "leak"' --last 2h
• 关注输出中是否频繁出现 zalloc: allocation failed 或 kern.zalloc: potential leak detected 类报错
• 若某条日志反复关联同一 kext 名称（如 prl_、socnet、avast），就是强证据