Exchanger仅支持两线程配对交换，大规模应用需拆解为独立成对单元并独占实例；必须避免共享、复用线程池、重操作夹杂exchange；应复用缓冲区、校验数据、设超时降级、统一协议并禁传null。
Exchanger 本身不处理“大规模任务并发”，它只服务两个线程的配对交换。想用它支撑大规模协作，关键不是让它变“大”，而是把大规模任务拆解成多个独立的、严格成对的协作单元，每个单元独占一个 Exchanger 实例。
必须按对隔离，不能共享实例
一个 Exchanger 实例只能绑定两个线程。如果让 100 个线程共用同一个实例，前两个可能成功交换，剩下 98 个会全部阻塞等待——它没有队列、不排队、不轮换，卡死是必然结果。
- 正确做法：按业务逻辑划分协作对，比如每组图像处理任务分配一对线程（渲染+显示）+ 一个专属 Exchanger 实例
- 避免线程池复用：FixedThreadPool(2) 提交多个任务时，线程会被回收再分配，导致上一轮未完成的等待残留，新任务无法配对
- 动态扩缩容需配套管理：新增任务对时，新建 Exchanger；任务结束时，确保双方都已退出 exchange 循环，避免残留等待
交换动作必须轻量，否则拖垮整体吞吐
Exchanger 的交换本身是原子引用移交，毫秒级完成。但若在调用前后夹杂重操作（如序列化、IO、GC 压力大的对象构造），就会拉长配对窗口，让另一方空等，实际吞吐反而下降。
- 数据准备和消费逻辑必须放在 exchange() 外：填满 buffer → exchange() → 立即开始下一轮处理，不要在 exchange 内做任何计算
- 缓冲区复用是刚需：提前分配好两块 ByteBuffer 或 byte[]，循环使用，避免每轮 new 导致 GC 频繁
- 收到对方 buffer 后先校验再用：检查 position/limit 是否合理、内容是否非空，防止因上游异常导致下游 NPE 或解析失败
超时是大规模部署的生命线
无超时的 exchange(V) 在小规模测试中可能正常，但在大规模部署中极易引发级联故障——一个线程因 GC 暂停或网络抖动延迟 2 秒，它配对的线程就卡住 2 秒，进而拖慢整个任务组。
立即学习“Java免费学习笔记（深入）”；
- 强制使用带超时版本：exchange(data, 3, TimeUnit.SECONDS)，超时时间设为典型处理耗时的 2–3 倍
- 超时后必须降级：跳过当前批次、记录告警、触发备用流程（如返回默认帧、走降级算法），不能只打日志
- 捕获 InterruptedException 后立即恢复中断状态：Thread.currentThread().interrupt()，确保上层能感知并终止任务
类型与状态约定比语法更重要
泛型保证编译期类型一致，但运行时语义靠协作规范。大规模场景下，一旦某对线程因 buffer 状态混乱（如未 clear 就 reuse）导致数据错乱，问题会快速扩散。
- 统一缓冲区协议：双方约定每次 exchange 后必须调用 clear() 或 compact()，并在文档中标明
- 禁止传 null：用哑值替代（如 new byte[0]），避免下游空指针且难以定位源头
- 缓冲区实例在线程内长期持有：不要跨线程传递、不要在 exchange 中 new 新对象，减少内存压力和 GC 波动
