lineunavailableexception 主因是系统音频资源被其他程序独占或设备异常，需通过重试、枚举备用混音器、严格释放资源及用户提示综合解决。
LineUnavailableException 通常不是代码写错了，而是系统音频资源被其他程序独占导致的——Java 音频 API（如 AudioSystem.getLine()）无法获取到可用的音频线路。
为什么 LineUnavailableException 会抛出
Java 的 javax.sound.sampled 包在打开音频线路（如 SourceDataLine 或 TargetDataLine）时，底层会向操作系统申请硬件或混音器资源。如果该线路正被另一个进程（比如 Chrome、QQ、Zoom、甚至另一个 Java 进程）以独占模式占用，或者系统默认音频设备被禁用/断开，getLine() 就会直接抛出 LineUnavailableException，而不是等待或降级。
常见触发场景包括：
- Windows 上使用了「独占模式」的播放设备（右键音量图标 → 声音 → 播放 → 属性 → 高级 → 勾选“允许应用程序独占控制该设备”）
- Mac 上 Core Audio 被其他 App 锁定（如 QuickTime Player 正在录音）
- Linux 使用 PulseAudio 但未启用模块（如
module-null-sink）或权限不足 - 同一 JVM 内多次调用
line.open()未正确关闭前一个实例
捕获并重试：基础防御策略
不能假设第一次 getLine() 就成功。必须用 try-catch 包裹，并加入有限重试和延迟，给系统释放资源留出时间窗口。
立即学习“Java免费学习笔记（深入）”；
try {
line = (SourceDataLine) AudioSystem.getLine(info);
line.open(format, bufferSize);
} catch (LineUnavailableException e) {
System.err.println("音频线路暂不可用，200ms 后重试...");
try {
Thread.sleep(200);
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
return;
}
// 可递归或循环重试（建议最多 3 次）
}
注意：Thread.sleep() 不是万能解药，但能避开瞬时竞争；不要无限制重试，避免卡死 UI 或线程。
主动选择备用线路而非硬刚默认设备
不依赖 AudioSystem.getLine(info) 的默认行为，而是枚举所有可用线路，跳过已知高冲突设备（如 Windows 的“立体声混音”或“Wave Extensible”），优先选通用混音器（Mixer.Info 中含 “Java Sound Audio Engine” 的）。
关键步骤：
- 调用
AudioSystem.getMixerInfo()获取全部混音器列表 - 对每个
Mixer调用mixer.isLineSupported(info)判断是否支持目标DataLine.Info - 跳过名称含
"Stereo Mix"、"What U Hear"、"CABLE Input"等易被占用的线路 - 优先尝试
AudioSystem.getMixer(null)返回的默认混音器（它通常是软件混音器，冲突概率低）
释放资源比捕获异常更重要
90% 的重复 LineUnavailableException 来自前一次使用后没调用 line.close() 或 line.drain()。尤其在异常路径中，容易遗漏清理逻辑。
务必确保：
- 所有
open()都对应一个成对的close()，且放在finally块里 - 写入音频数据后，若调用
line.stop()，应先line.drain()再close()，否则缓冲区残留可能导致下一次open()失败 - 避免在
static字段中长期持有SourceDataLine实例——它不会自动回收，会持续占用线路
最稳妥的模板：
SourceDataLine line = null;
try {
line = (SourceDataLine) AudioSystem.getLine(info);
line.open(format);
line.start();
// ... write audio data
} catch (LineUnavailableException e) {
// handle
} finally {
if (line != null) {
line.drain(); // 等待缓冲区播完
line.close(); // 彻底释放
}
}
真正难处理的不是异常本身，而是音频设备状态不可见、不可预测。与其反复重试，不如在首次初始化时就做混音器探测 + 用户提示（例如弹窗：“检测到麦克风被占用，请关闭会议软件后重试”），这比纯技术绕过更可靠。
