Exchanger怎么在双缓冲里交换两个缓冲区
Java 的 Exchanger 本质是线程间**成对同步交换对象**的工具，用在双缓冲场景时，它不负责分配内存、不管理读写状态，只管“等两个线程都到齐了，就互换手里的缓冲区引用”。典型用法是：一个线程持续往 A 缓冲区填数据（生产），另一个线程从 B 缓冲区取数据处理（消费），填满/取空后双方调用 exchange() 换一次引用，角色轮转。
- 必须严格成对调用 —— 一个线程调用
exchange(buffer)后，必须有且仅有一个另一线程在同一Exchanger实例上调用exchange()，否则前者会一直阻塞 - 不能用同一个
Exchanger混合多个缓冲对，比如 A/B 一组、C/D 另一组，得用两个独立实例 - 缓冲区对象本身最好是可重用的（如
ByteBuffer或自定义数组容器），交换的只是引用，避免频繁创建对象
为什么不用 wait/notify 或 BlockingQueue
双缓冲的核心诉求是**零拷贝切换 + 精确配对**。wait/notify 需手动维护状态变量和锁，容易漏 notify 或虚假唤醒；BlockingQueue（如 ArrayBlockingQueue）虽能传缓冲区，但它是“生产者推、消费者拉”，无法保证“填满立刻交出，且对方正好准备好接收”——中间可能堆积或空等。而 Exchanger 天然强制双方同步点对点交接，语义更贴近双缓冲的节奏感。
-
Exchanger无内部队列，不缓存数据，交换即完成，延迟更低 - 没有容量限制，不会因队列满导致生产者阻塞在错误位置（比如还没填满就卡住）
- 但代价是：如果某一方崩溃或长期不调用
exchange()，另一方会永久阻塞 —— 这不是 bug，是设计使然
常见阻塞卡死现象和排查点
最常遇到的是线程 A 调用了 exchange() 后一直停在那儿，jstack 显示 java.util.concurrent.Exchanger$Node.block。这不是死锁，而是另一端没来。
- 检查是否漏写了另一端的
exchange()调用，尤其在异常分支或循环退出条件里 - 确认两个线程用的是同一个
Exchanger实例 —— 常见错误是每次 new 一个新实例 - 注意线程生命周期：如果消费者线程提前结束（比如处理完一批数据就 return），生产者下次
exchange()必然卡死 - 不要在
exchange()前后加耗时操作（如日志、IO），否则会放大等待时间，掩盖真实问题点
简单示例：ByteBuffer 双缓冲交换
下面这段代码演示核心交换逻辑，省略了缓冲区复位等细节，重点看 exchanger.exchange() 的位置和参数传递：
立即学习“Java免费学习笔记（深入）”；
Exchanger<ByteBuffer> exchanger = new Exchanger<>();
ByteBuffer bufA = ByteBuffer.allocate(1024);
ByteBuffer bufB = ByteBuffer.allocate(1024);
// 生产线程
new Thread(() -> {
while (running) {
fillData(bufA); // 往 bufA 写数据
bufA.flip();
try {
bufA = exchanger.exchange(bufA); // 交出 bufA，拿到对方的缓冲区（原 bufB）
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
bufA.clear(); // 清空刚换来的缓冲区，准备下一轮写
}
}).start();
// 消费线程
new Thread(() -> {
while (running) {
try {
ByteBuffer consumed = exchanger.exchange(bufB); // 交出 bufB，拿到刚填满的 bufA
processData(consumed); // 处理数据
consumed.clear(); // 清空后交还给生产者
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}).start();
注意：bufA 和 bufB 初始值不同，但交换后引用会来回切换；clear() 必须在交换后立即调用，否则下次写入会覆盖未处理完的数据。
双缓冲真正的难点不在交换动作本身，而在缓冲区边界控制 —— 比如写入中途被中断、读取时发现缓冲区没填满、或者需要支持部分交换。这些都得靠上层逻辑兜底，Exchanger 只管“换”，不管“对不对”。
