为什么不用现成的 ConcurrentHashMap
很多人写 Producer 封装会用 ConcurrentHashMap<TopicPartition, Queue<ProducerRecord>>------每来一条消息塞进去，后台线程消费。功能上没问题，但性能差一个数量级。
Kafka 没有这么做。它花了很大力气设计自己的数据结构，核心目标三个：
- 攒批：多条消息合并成一个网络请求，而不是每条一次请求
- 内存复用：避免频繁 new/delete ByteBuffer，减少 GC
- 背压：Producer 不能无限快地往 Broker 塞，需要限流
01 Deque：为什么不是 Queue
每个分区的批次队列用的是 Deque<ProducerBatch>，不是普通的 Queue。原因是读写两端不同：
- 写端（right）：业务线程把新批次加到队尾，正在攒批
- 读端（left）：Sender 线程从队头拉 ready 批次发出去
- 失败重传：一个批次发出去但 ACK 失败，要重新入队------插到队头，不是队尾
为什么重传要插队头？因为这个批次已经写满了，是 ready 的，应该尽快重试。如果插到队尾，后面攒的新批次会排在它前面------新批次还没攒满，要等很久才发，导致重传延迟。
Deque 的 addFirst() 和 pollLast() 都是 O(1)，两端操作互不影响。普通 Queue 做不到这一点。
02 BufferPool：为什么要自己实现内存池
如果每个批次都 ByteBuffer.allocate(16KB)，发完了 ByteBuffer 不引用了等 GC，会发生什么？
- GC 压力：每秒几万个 ByteBuffer 对象，Young GC 频繁，STW 影响延迟
- 内存碎片：16KB 的块反复分配释放，堆碎片化
- 分配开销：Java NIO 的 allocate 本身有开销
Kafka 的做法是自己做一个池：
buffer.memory = 33554432（32MB）
batch.size = 16384（16KB）32MB 总内存切成 2048 个 16KB 的块，放在一个 free: Deque<ByteBuffer> 里。
分配时 ：free 队列里有空块就直接 pollFirst()，没有就 new 一个。如果总内存超了（32MB 用完了），业务线程阻塞在 memoryAvailable.await()，等 ACK 回来释放块。
释放时 ：ACK 回来，批次从 incomplete 移除，ByteBuffer 放回 free 队列，signalAll() 唤醒等待者。
整个过程没有 ByteBuffer 被 GC------32MB 的块循环使用，长期运行内存占用稳定。这就是为什么 Kafka Producer 跑一天 OOM 问题很少（除非配置错了）。
线上踩过的坑：buffer.memory 设得太小。50 个分区每个攒一个 16KB 批次就是 800KB，看起来不多，但如果 Broker 响应慢（比如跨机房），批次都在 incomplete 里不释放，32MB 很快用完，业务线程阻塞 60 秒后抛异常。症状就是"偶发性 send 超时"------调大 buffer.memory 或排查 Broker 网络。
03 InFlightRequests：为什么要限制在途请求数
默认 max.in.flight.requests.per.connection = 5。意思是：每个 TCP 连接上，最多有 5 个未收到 ACK 的请求同时在飞。
为什么要有这个限制？
不限制会怎样？ Producer 可以同时发 1000 个请求给 Broker，Broker 处理不过来，内存被打爆，最后 OOM 崩溃。Producer 不是"越快越好"------它要和 Broker 的处理能力匹配。
限制了会怎样？ 第 6 个请求必须等前面某个请求 ACK 回来。这天然形成了背压------Producer 的发送速度不会超过 Broker 的处理速度。
还有个副作用：acks=0 或 acks=1 时，消息乱序风险。如果第 1 个请求慢、第 2 个请求快，第 2 个先到 Broker，同分区的两条消息顺序就反了。要严格保证顺序，设 max.in.flight.requests.per.connection=1------但性能会掉一半以上。大部分业务接受弱顺序（同一用户的消息不要求严格有序），保留 5 这个默认值。
04 ConcurrentMap：分区之间无锁
batches 是 ConcurrentHashMap<TopicPartition, Deque<ProducerBatch>>。
为什么不用普通 HashMap？因为多个业务线程同时 send 不同分区时，ConcurrentHashMap 只锁桶，两个线程写不同分区完全并行。如果用 synchronized HashMap，所有 send 都串行化------多线程 Producer 等于单线程。
同一个分区的 append 还是要加锁的（synchronized on the deque），但不同分区之间零竞争。这就是为什么 Kafka Producer 在多线程场景下吞吐能线性提升------分区数越多，并发度越高。
05 写在最后
Kafka Producer 的高性能不是某个魔法参数，而是数据结构的选择：Deque 解决攒批和重传，BufferPool 解决 GC，InFlightRequests 解决背压，ConcurrentHashMap 解决多线程并发。理解了这四个结构，就理解了为什么 batch.size、linger.ms、buffer.memory、max.in.flight 这些参数是这样设计的------每一个都对应一个数据结构的行为。