macOS应用长时间运行后CPU利用率骤降及线程数异常排查咨询

优先级判断 #

优先聚焦**线程数飙升至3000+**的问题——这是导致CPU利用率异常下降的核心诱因（系统线程调度过载，有效任务无法正常执行）。内存问题暂按低优先级处理，但需注意线程泄漏可能与内存管理（如循环引用）相关。

具体排查步骤 #

一、定位线程泄漏根源 #

• 使用Instruments的Thread Profiler启动长时间后台录制（无需等待突变时刻），过滤重复创建的线程，查看调用栈定位来源：
  • 检查FetchAudioData的Timer是否触发了未回收的异步任务
  • 排查MEMU/FullScreen图形操作中是否存在未正确释放的绘图线程或队列
  • 验证GCD/NSOperation是否存在无限制创建线程的逻辑（如未设置并发数上限）
• 终端实时监控：用ps -M <进程PID>跟踪线程数变化，当线程数开始快速上涨时，用lldb attach <PID>暂停进程，遍历所有线程的调用栈，锁定重复创建的线程类型

二、分析CPU突变的关联因素 #

• CPU骤降时，用top -pid <PID>查看进程状态（是否处于不可中断睡眠），配合vm_stat和thread_stat检查系统资源（文件描述符、端口等）是否耗尽，导致线程无法调度
• 验证FetchAudioData的Timer有效性：Timer依赖RunLoop，若RunLoop被阻塞或所在线程挂起，会停止触发数据捕获。添加Timer触发日志，或用Instruments的RunLoop Profiler查看RunLoop循环状态
• 检查图形组件异常：排查MEMU/FullScreen是否存在图形上下文泄漏、Metal/Cocoa绘图队列阻塞，导致图形任务堆积、线程无法释放

三、代码层面快速验证 #

• 限制异步任务并发数：给GCD并发队列设置dispatch_set_target_queue绑定到有限并发的队列，或给NSOperationQueue设置maxConcurrentOperationCount，避免无限制创建线程
• 替换Timer为CADisplayLink：更适合实时图形同步的场景，避免Timer因RunLoop状态异常失效
• 排查循环引用：用Instruments的Leaks工具录制，检查是否存在线程持有的对象无法释放的情况（循环引用可能间接导致线程泄漏）

四、系统层面排除干扰 #

• 在不同macOS版本（如Ventura/Sonoma）测试，确认是否为系统级线程调度Bug
• 关闭系统节能模式、自动显卡切换等功能，排除系统资源限制影响
• 查看Console.app中的进程相关日志，搜索线程创建失败、资源耗尽的错误提示

内容的提问来源于stack exchange，提问作者Hajime