카프카 프로듀서는 메시지를 전송할 때 ByteBuffer를 사용한다. ByteBuffer는 생성하는 쓰레드에서 큰 메모리 단위를 생성하거나 여러 버퍼에 할당된 메모리를 해제할 때 쓰레드는 기아가 되거나 데드락이 될 수 있다. 이런 문제 때문에 프로듀서는 BufferPool을 사용한다. 이 BufferPool은 충분한 메모리가 확보 될 때 까지 쓰레드를 기다리게 할 수 있고, 이미 생성된 ByteBuffer를 재사용 할 수 있으며, 제한된 메모리로 동작할 수 있게 한다. 실제 BufferPool.java 는 메트릭 관련 코드도 있고 다른 변수들이 있어 예시보다는 쬐~금 복잡하지만 allocate와 deallocate 부분만 간단히 구현해보고 메모리를 제한하는 방법과 쓰레드를 처리하는 동작 방식에 대해 알아 두기로 한다. 코드를 보기 앞서 ByteBuffer.allocate와 ReentrantLock에 대해 먼저 알아보자. ByteBuffer.allocate vs ByteBuffer.allocateDirect BufferPool은 allocate를 사용한다. 왜 allocateDirect를 사용하지 않는지는 여기 에 설명 되어 있는데, 간단히 요약하면 아래 정도의 내용이 된다. 생명주기가 짧거나 자주 사용되지 않는 객체에는 다이렉트 버퍼를 사용하지 않아야 한다. 왜냐하면, 다이렉트 버퍼는 OS 종속적인 네이티브 코드를 사용하기 때문에 힙기반 버퍼보다 생성과 메모리 반환 비용이 높고 가비지 컬렉터의 영역 밖이라 메모리 누수가 있을 수 있다. 용량이 큰 다이렉트 버퍼를 빈번하게 할당하면 OutofMemorryError가 생길 수 있다. 그리고, FileChannel 에서 non-direct Buffer와 direct Buffer 속도비교 ( FileChannel and non-direct buffer vs. FileChannel and direct buffer , 중국어! 코드와 그림만 보자) 버퍼가 256KB보다 작