創造のメモリとリリースがより多くのである生産者がカフカを送ることを私たちは皆知っているが、メモリ上に保存直接サーバーにカフカレコード（記録）した後に送信されますが、していない（RecordAccumulator）、圧縮後のために送られたバッチ、資源消費は、メモリの効率的な使用を達成するために、それぞれ実質的に洗練されたツールは、フレームまたはメモリ管理を有する、カフカバッファー・プロデューサは、メモリ（のByteBufferのJavaのNIO）多重化を実現するために使用します。
それは何であるBUFFERPOOL？図1：
図1は、（buffer.memoryによって構成される）totalMemoryで表される赤色及びバッファプールの緑の合計量を表す、二つの部分の合計を含み、代表的には、緑の空間を使用することができ、それは二つの部分を含む：上部は、アプリケーションがない表します下半部代表に適用が、使用しない、ByteBufferのキュー（のDeque <ByteBufferの>）で発現している、我々は、このキューが空いている呼び出し、キューのサイズはByteBufferのはによって（poolableSizeで表され、部分的に表すavailableMemoryで使用batch.size構成）。
図2は、バッファプールから固定メモリサイズの大きさを割り当てるステップを要約したものです。
図2のメモリの要求サイズの大きさから分かる有するようSaengsam 2より大量のメモリのアプリケーションように、いくつかのエンドモード（赤枠部）、1、異常終了、ByteBufferの直接割り当てられたキューメモリ; 3 avaliableMemoryにメモリを割り当てます。
蓝色框内的为大多数的内存分配方式，就是从队列中直接拿想要的ByteBuffer，也是kafka希望的分配方式；黄色的框为分配内存时队列中的内存不符合其分配的条件（队列为空或大小不匹配），从availableMemory中分配；绿色框为当前内存池中内存不足时阻塞等待的情况，具体就是有一个累加器accumulated，如果累加器没有累加到size大小，说明还没有足够的内存释放出来，所以就会阻塞等待内存释放，内存释放之后会唤醒阻塞的线程，将可以分配的内存大小累加到累加器accumulated上，这样直到累加器accumulated大小满足size，就直接分配。这里面还有一个原则就是如果还没给累加器accumulated累加过一次的话，也就是accumulated==0的时候，那么会优先尝试从队列中获取内存（有可能释放的内存释放到队列中）。
释放内存的话就比较简单了，如果释放的大小等于poolableSize的话，就把它放入free队列，否则释放到availableMemory中(availableMemory+=size)。所以只有固定大小的内存块被释放后才会进入池化列表，非常规释放后只会增加可用内存大小。
BufferPool是线程安全的，用一个ReentrantLock来保证，并且用一个Deque<Condition> waiters队列来记录申请不到足够空间而阻塞的线程，此队列中实际记录的是阻塞线程对应的Condition对象，如图3所示，将阻塞线程对应的Condition加入队列，等待唤醒，唤醒的顺序根据入队顺序决定(先进先出)。
总结：
0. 可以看到BufferPool只针对特定大小(poolableSize)的ByteBuffer进行管理，对于其它大小的并不会缓存进来。因此如果超大消息比较多(大于poolableSize)，就不会很好的利用内存池，频繁的申请回收内存效率会降低，并可能带来Full GC或者Out Of Memory Error，这个时候就要调整好batch.size的配置了。
1. BufferPool是线程安全的，用一个ReentrantLock来保证。
2. BufferPool只针对特定大小的ByteBuffer进行管理，对于其它大小的并不会缓存进来。因此如果超大消息比较多(大于poolableSize)，就不会很好的利用内存池，频繁的申请回收内存效率会降低，并可能带来Full GC或者Out Of Memory Error，这个时候就要调整好batch.size的配置了
