Java实时录音实现：麦克风采集代码详解

本文深入剖析了Java中实现麦克风实时录音的核心难点与实战方案，直击开发者常踩的三大陷阱：误用AudioSystem.getAudioInputStream处理原始PCM流导致UnsupportedAudioFileException、因设备抢占或权限问题引发的LineUnavailableException，以及缓冲区设计不当引起的高CPU占用与延迟失衡；文章不仅给出清晰可靠的TargetDataLine采集代码范例，还详解了WAV文件头的手动构造逻辑、跨平台兼容性注意事项，并提供了降低延迟、避免内存抖动、解耦IO操作等关键优化策略，是Java音频开发从入门避坑到生产落地的实用指南。

AudioSystem.getAudioInputStream 为什么总抛 UnsupportedAudioFileException

常见原因是传入了不支持的音频格式或设备流。Java Sound API 的 AudioSystem.getAudioInputStream 只能处理已知编码的文件（如 WAV、AIFF），**不能直接用于麦克风实时流**。试图对 TargetDataLine 调用它会失败——因为麦克风数据是原始 PCM 流，没有文件头。

正确做法是跳过这一步，直接从 TargetDataLine 读取字节：

AudioFormat format = new AudioFormat(
    AudioFormat.Encoding.PCM_SIGNED,
    44100.0f, // sample rate
    16,       // sample size in bits
    2,        // channels
    4,        // frame size
    44100.0f, // frame rate
    false     // big endian
);
DataLine.Info info = new DataLine.Info(TargetDataLine.class, format);
TargetDataLine line = (TargetDataLine) AudioSystem.getLine(info);
line.open(format);
line.start(); // 开始采集
<p>byte[] buffer = new byte[4096];
int bytesRead;
while (recording) {
bytesRead = line.read(buffer, 0, buffer.length); // 直接读，别 wrap 成 InputStream
// 处理 buffer 中的 PCM 数据
}</p>

如何避免 LineUnavailableException 启动失败

这个异常几乎总是因为：同一时间有其他程序占用了麦克风（如 Zoom、Teams、系统录音机），或 JVM 没有权限访问音频设备（尤其在 macOS 或 Linux 的 sandbox 环境中）。

• 检查是否已有 TargetDataLine 在运行：调用前先 line.isRunning() 或确保 close() 旧实例
• 显式指定设备而非依赖默认：用 AudioSystem.getMixer(null) 列出所有混音器，挑出带 "Microphone" 或 "Capture" 字样的
• Linux 下可能需加入 audio 用户组；macOS 需在「系统设置 → 隐私与安全性 → 麦克风」中允许 Java 应用

实时录音时 CPU 占用飙升，怎么压低延迟又不卡顿

核心矛盾在于缓冲区大小：buffer 太小 → 频繁 read() 调用，上下文切换多；太大 → 延迟高、响应滞后。4096 字节（约 23ms @ 44.1kHz/16bit/stereo）是较稳妥起点。

更关键的是别在 read() 循环里做重操作：

• 不要在循环内新建对象（如 new ByteArrayOutputStream()）
• 避免同步 IO（如边录边写磁盘 WAV 文件）——改用双缓冲队列 + 独立写线程
• 若需实时 FFT 或降噪，优先用 float[] 批量转换（用 AudioFormat 的 getSampleSizeInBits() 和 isBigEndian() 正确解析 PCM）

保存为 WAV 文件必须手动写 header

Java Sound API 不提供“把 raw PCM 流自动封装成 WAV”的工具类。WAV 是 RIFF 容器格式，header 固定 44 字节，含采样率、位深、声道数等字段。漏写或写错会导致播放器无法识别。

最简 header 构造逻辑（适用于 PCM_SIGNED, 16-bit, stereo）：

public static byte[] wavHeader(int byteRate, int audioDataLength) {
    byte[] header = new byte[44];
    // "RIFF"
    header[0] = 'R'; header[1] = 'I'; header[2] = 'F'; header[3] = 'F';
    // file size = 36 + audioDataLength
    writeInt(header, 4, 36 + audioDataLength);
    // "WAVE"
    header[8] = 'W'; header[9] = 'A'; header[10] = 'V'; header[11] = 'E';
    // "fmt "
    header[12] = 'f'; header[13] = 'm'; header[14] = 't'; header[15] = ' ';
    // format chunk size = 16
    writeInt(header, 16, 16);
    // format = 1 (PCM)
    writeShort(header, 20, (short) 1);
    // channels = 2
    writeShort(header, 22, (short) 2);
    // sampleRate = 44100
    writeInt(header, 24, byteRate / 4); // 注意：byteRate = sampleRate * channels * bitsPerSample/8
    // byteRate
    writeInt(header, 28, byteRate);
    // blockAlign = channels * bitsPerSample/8
    writeShort(header, 32, (short) 4);
    // bitsPerSample = 16
    writeShort(header, 34, (short) 16);
    // "data"
    header[36] = 'd'; header[37] = 'a'; header[38] = 't'; header[39] = 'a';
    // subchunk2Size = audioDataLength
    writeInt(header, 40, audioDataLength);
    return header;
}

header 写完后，再追加原始 PCM byte[] ——顺序不能反，长度不能错。

真实项目里最容易被忽略的，是不同平台对 TargetDataLine 缓冲行为的差异：Windows 上默认 buffer 可能偏大，Linux ALSA 有时会静默丢帧，而 macOS CoreAudio 对 open() 的 millisecondTimeout 参数更敏感。别假设一次参数适配全平台。

今天关于《Java实时录音实现：麦克风采集代码详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！