根本原因是音频采集线程与JVM线程调度不同步导致的「虚假空读」；TargetDataLine.read()不保证填满缓冲区，必须严格依据返回值len处理有效数据，避免依赖available()、正确转换PCM字节序、合理控制缓冲区大小与读取节奏，并确保stop()与close()成对调用。
为什么 TargetDataLine.read() 返回值经常是 0 或远小于请求长度？
根本原因不是代码写错了，而是音频采集线程和 JVM 线程调度不同步导致的「虚假空读」。Java 的 TargetDataLine 是基于底层音频子系统（如 ALSA、CoreAudio、Windows WASAPI）的缓冲区抽象，它不保证每次 read() 都填满你传入的字节数组——哪怕缓冲区已就绪，也可能只返回几十字节。
常见错误是写成这样：
byte[] buffer = new byte[1024]; int len = line.read(buffer, 0, buffer.length); // ❌ 错误假设 len == buffer.length // 直接把 buffer 全部当作有效数据处理
正确做法必须严格依据返回值 len 处理有效字节：
-
len为 0：说明当前无新数据，应跳过或做空闲等待（但别 busy-wait） -
len为负数：表示线程中断或流已关闭，需退出循环 -
len > 0：仅处理buffer[0]到buffer[len - 1]这段数据
如何避免 TargetDataLine 缓冲区溢出或欠载？
溢出（overflow）发生在你读得太慢，底层音频缓冲区被新采样覆盖；欠载（underflow）则相反——读得太快，缓冲区没数据可读，read() 频繁返回 0。两者都源于读取节奏与音频帧率不匹配。
立即学习“Java免费学习笔记（深入）”；
关键控制点在三处：
-
缓冲区大小设置：用
AudioFormat构造时指定的frameSize和frameRate决定了每秒数据量，调用DataLine.Info时传入的缓冲区大小（单位字节）建议 ≥ 2 倍单秒数据量，例如 44.1kHz / 16-bit / mono → 每秒约 88KB，缓冲区至少设为176_000字节 -
读取频率：不要用 while(true) +
read()，改用固定周期定时读（如每 20ms 读一次），可用ScheduledExecutorService控制节奏 -
线程优先级：采集线程建议设为
Thread.MAX_PRIORITY（仅限桌面环境），避免被 GC 或其他线程抢占过多 CPU 时间
TargetDataLine 的 available() 方法到底能不能信？
不能全信，尤其在 Windows 上几乎不可靠。available() 返回的是「当前可读字节数估算值」，不是精确值，且部分音频驱动根本不更新该值，始终返回 0 或恒定小值。
典型误用：
if (line.available() > 0) {
line.read(buffer, 0, buffer.length); // ❌ 依赖 available() 触发 read，漏数据风险高
}更稳妥的方式是直接调用 read() 并检查返回值，或结合 isRunning() + 轮询延迟：
- 先
line.start()，再进循环 - 每次
read()后，若len == 0，Thread.sleep(1)避免空转 - 避免用
available()做主逻辑分支判断
读到的原始 PCM 数据怎么转成有符号短整型数组？
Java 默认音频格式（AudioFormat.Encoding.PCM_SIGNED）是小端序、16-bit、有符号，但 TargetDataLine.read() 返回的是 byte[]，需手动按字节对重组为 short[]。错位会导致声音严重失真（如变成尖啸或静音）。
正确转换逻辑（以 little-endian 为例）：
byte[] audioBytes = new byte[1024];
int len = line.read(audioBytes, 0, audioBytes.length);
short[] samples = new short[len / 2];
for (int i = 0; i < len; i += 2) {
// 小端：低字节在前，高字节在后
samples[i / 2] = (short) ((audioBytes[i] & 0xFF) | (audioBytes[i + 1] << 8));
}注意点：
- 务必确认
AudioFormat的isBigEndian属性，Mac 默认大端，Windows/Linux 通常小端 - 如果格式是
PCM_UNSIGNED（少见），需额外减去 32768 再转short - 不要用
ByteBuffer.wrap(...).order(...).asShortBuffer().get(...)直接拷贝——某些 JVM 版本存在字节序 bug，手动拆解最稳
真实项目里最容易被忽略的，是采集线程生命周期和 TargetDataLine 关闭顺序。stop() 和 close() 必须成对调用，且 close() 前要确保读循环已退出，否则可能触发 native 层资源泄漏，表现为后续几次启动采集失败或系统音频服务卡死。
