Godot 的音频系统有两类线程在跑：音频线程（驱动回调驱动，每 mix buffer 周期一次，干所有混音的活）和游戏线程（你的 _process，想什么时候碰音频 API 就什么时候碰）。两者共享 AudioServer 的状态，同步靠什么、哪里会撞车、撞了多疼——这是音频性能问题里最容易被忽视的一层。
线程模型：硬性实时约束
音频线程由驱动的输出回调驱动。CoreAudio/WASAPI/ALSA 的共同契约是：回调来了，你把 $N$ 帧采样写进输出缓冲，必须在下一个回调到来前返回——这个期限是硬性的，超时的后果不是"慢一点"，是输出设备 underrun，用户听到的是咔哒声和断音。48kHz、512 帧缓冲下期限是 10.7ms，缓冲调到 128 帧就只有 2.7ms。
这个回调里干的活是全套混音：遍历所有激活的 playback 拉数据（可能触发解码线程交互）、按 bus 树累加、跑每个 bus 的效果器链、写输出。也就是说音频线程的负载是实时预算里最贵的一段，而锁竞争直接吃掉这段预算。
锁在哪：不是所有 API 都进临界区
翻看 scene/audio/ 和 servers/audio_server.cpp 会发现 Godot 4.x 对游戏线程的音频 API 做了大量命令队列化处理：AudioStreamPlayer.play() 这类操作不是直接改服务器状态，而是把命令打包进队列，由音频线程在混音间隙自己消费——这是现代游戏引擎的标准做法（Unreal 的 audio command queue 同理），为的就是避免游戏线程拿锁。所以你日常调 play()/stop() 基本是无锁的。
但有几类调用确实跨线程取锁，都集中在"要立刻拿到数据"的接口上：
AudioEffectCapture.get_buffer()（八-8 的回采）——读环形缓冲要锁；AudioStreamGeneratorPlayback.push_frame()——写环形缓冲；AudioServer.get_time_since_last_mix()、get_output_latency()等查询；- 效果器参数的某些 setter（具体看实现，4.x 大部分已命令化，但第三方 GDExtension 效果器未必）。
判断方法很直接：凡接口文档里写了"音频线程安全"或返回当前状态的查询，基本都在临界区里。锁本身是一把普通 mutex，临界区短，单次拿不到几微秒——问题只在频率：每帧调几百次和每帧调几次是两个世界。
实测：放大法
锁竞争的问题在于正常项目里它藏得很好——单次微秒级，混音 3ms、期限 10.7ms，余量厚。要看见它就得把余量压掉：项目设置把混音缓冲调到 128 帧（audio/driver/mix_buffer_size，部分平台生效），期限立刻缩到 2.7ms。然后在 _process 里人为制造高频临界区调用，比如 500 次 get_buffer(1)，边放音乐边听——正常时音频干净，撞锁时混音被推迟、回调逼近期限，出现咔哒。这个实验最有价值的产出是你自己的黑名单：逐个试你项目用到的音频 API，哪些一高频调用就出声，哪些无感。结论大概率是：命令化的 play/stop/seek 无感，缓冲读写类有感。
工程结论
第一，把"每帧少量多次"的音频调用合并成"每帧一次批量"：八-8 里 get_buffer(512) 而不是 512 次 get_buffer(1)，持锁次数从 512 降到 1。第二，别在 _process 里做音频数据的数值计算——分析放工作线程（WorkerThreadPool，一-18），算完只把结果拿回主线程。第三，第三方 GDExtension 音频效果器要格外小心：它们跑在音频线程里，任何一次分配内存、一次日志打印都直接计入那 10.7ms 预算，插件作者没注意的话你排查起来会像在抓鬼。
如果项目真的出现"人一多/枪一多就音频爆"，排查顺序是：先开 profiler 看混音耗时本身（bus 数 × 效果器数是固定开销大头），再查本节的锁竞争，最后才怀疑解码器。八成的问题死在第一关——bus 上挂了十几个效果器，那 10.7ms 是被自己花掉的，不是被偷走的。
本文基于 Godot 4.2–4.4；命令队列化是 4.x 的既有行为，具体哪些接口进临界区以所用版本的 servers/audio_server.cpp 为准。