WAIT_BLOCKED线程状态含义解析：AudioTrack线程lttng trace分析场景

在分析Android的AudioTrack线程LTTng trace时遇到卡顿（glitch）时线程显示为WAIT_BLOCKED，这其实是Linux/Android线程模型里一个很明确的状态标识，我来给你拆解清楚：

核心含义 #

WAIT_BLOCKED状态意味着当前线程主动放弃了CPU的使用权，进入阻塞等待状态——它正在等待某个特定的资源、锁或者内核事件发生，在等待条件满足之前，调度器不会给这个线程分配CPU时间片。

结合AudioTrack场景的典型触发原因 #

当音频出现glitch时线程处于这个状态，大概率和音频播放的核心流程阻塞有关，常见的场景包括：

• 等待音频硬件设备的访问锁：如果系统里有其他进程/线程正在占用音频硬件（比如另一个App在播放音频），AudioTrack的播放线程会因为无法获取设备访问权限而阻塞
• 等待音频播放缓冲区填充：如果应用层向AudioTrack写入数据的速度跟不上播放速度，导致播放缓冲区耗尽，线程会阻塞等待新的音频数据写入
• 等待音频子系统的内核同步信号：比如等待AudioFlinger（Android音频服务）完成缓冲区的调度或者硬件的同步操作

示例截图说明 #

下面是LTTng trace中捕获到的AudioTrack线程处于WAIT_BLOCKED状态的典型截图：

如果要进一步定位具体的卡顿根因，你可以结合LTTng捕获的sched_switch、audio_track_write、audio_hw_open等相关事件，追踪线程阻塞前后的调用链路，就能明确是等待硬件、缓冲区还是其他同步资源导致的问题。

内容的提问来源于stack exchange，提问作者Ameer ali khan