概述
上节解析了生产者发送消息时RecordAccumulator的相关操作,本节解析下RecordAccumulator用到的其他组件BufferPool,CopyOnWriteMap
BufferPool缓冲池
上节讲到RecordAccumulator在append的时候会申请缓冲区,每个批次ProducerBatch在封装消息时MemoryRecordsBuilder会用到缓冲区ByteBuffer(MemoryRecordsBuilder和消息压缩这一块我觉得太边缘了,策略调整以后只解析关键流程和收获比较多的部分,其他的有机会再仔细分享)。
如果高频率的创建ByteBuffer有可能会造成虚拟机的频繁GC,这里kafka使用了BufferPool,BufferPool和数据库连接池的设计理念一样,是一个池子的概念,池子受一个最大使用内存的限制,需要就从池子申请一个ByteBuffer,不够用了就阻塞等待,用好了再还给池子并清空。
private final long totalMemory; //buffer.memory buffer容量
private final int poolableSize; //batch.size 批量大小
private final ReentrantLock lock; //防止多线程申请空间出现并发问题的重入锁
private final Deque<ByteBuffer> free; //空闲buffer队列
private final Deque<Condition> waiters; //等待分配buffer的队列
/** Total available memory is the sum of nonPooledAvailableMemory and the number of byte buffers in free * poolableSize. */
private long nonPooledAvailableMemory;//没分配到空闲队列的可用容量,totalMemory = poolableSize * free
allocate和deallocate
既然是个缓冲池,那么BufferPool主要提供两个api:借(allocate)和还(deallocate),这两个api流程比较简单。
allocate
- 对lock进行加锁。
- 如果空闲队列free里正好有同长度的,就直接出队并返回ByteBuffer。
- 如果空闲队列里所有的长度总和与nonPooledAvailableMemory大于申请的长度,循环释放掉空闲队列的ByteBuffer直到nonPooledAvailableMemory大于申请长度,并且重新初始化一个需要长度的ByteBuffer并返回。
- 如果所有可用(空闲队列里所有的长度总和与nonPooledAvailableMemory)还是小于申请长度,即不符合2的条件,那么就要阻塞等待了。这里先从lock初始化了一个条件变量Condition并放入等待队列,然后调用Condition的await阻塞等待,注意await会释放掉锁让其他线程拿锁执行直到接收到signal通知,接到通知后会继续执行,如果还不满足条件那么重复这一流程循环阻塞,直到拿到需要长度的ByteBuffer或者超时。
- 如果仔细分析一下,要是一个线程申请空间很大,其阻塞的时候其他线程就会一直执行并且用掉剩余空间,这样会产生饥饿啊,我个人理解kafka就是想通过这种机制来保证大容量ByteBuffer申请时不会影响正常容量ByteBuffer的申请。如果有频繁的大容量ByteBuffer申请,那考虑调整buffer.memory,batch.size这两个参数或者业务层面规避掉。
- 前面加了锁,finally千万别忘记释放掉。
- 前面只是保证容量够用,最后会初始化ByteBuffer。
public ByteBuffer allocate(int size, long maxTimeToBlockMs) throws InterruptedException {
//申请的容量比pool总容量还大,抛异常
if (size > this.totalMemory)
throw new IllegalArgumentException("Attempt to allocate " + size
+ " bytes, but there is a hard limit of "
+ this.totalMemory
+ " on memory allocations.");
ByteBuffer buffer = null;
this.lock.lock();
try {
// 有分配好的直接返回
if (size == poolableSize && !this.free.isEmpty())
return this.free.pollFirst();
// 看看剩余空闲容量多少
int freeListSize = freeSize() * this.poolableSize;
if (this.nonPooledAvailableMemory + freeListSize >= size) {
// 还够的话释放掉空闲的
freeUp(size);
// 没分配的容量先预扣掉
this.nonPooledAvailableMemory -= size;
} else {
// 剩余也不够
// accumulated 用来标记现在已经准备好了多少,如果异常了已经准备多少了得在finally里加回去,要不就泄露了
int accumulated = 0;
// 设置一个条件变量,用来线程间同步用
Condition moreMemory = this.lock.newCondition();
try {
//一直不够也不会一直等,设置一个最大等待时间
long remainingTimeToBlockNs = TimeUnit.MILLISECONDS.toNanos(maxTimeToBlockMs);
this.waiters.addLast(moreMemory);
// loop over and over until we have a buffer or have reserved
// 循环等待
while (accumulated < size) {
long startWaitNs = time.nanoseconds();
long timeNs;
boolean waitingTimeElapsed;
try {
//不够就先释放锁,然后阻塞
waitingTimeElapsed = !moreMemory.await(remainingTimeToBlockNs, TimeUnit.NANOSECONDS);
} finally {
long endWaitNs = time.nanoseconds();
timeNs = Math.max(0L, endWaitNs - startWaitNs);
this.waitTime.record(timeNs, time.milliseconds());
}
if (waitingTimeElapsed) {
throw new TimeoutException("Failed to allocate memory within the configured max blocking time " + maxTimeToBlockMs + " ms.");
}
remainingTimeToBlockNs -= timeNs;
// check if we can satisfy this request from the free list,
// otherwise allocate memory
if (accumulated == 0 && size == this.poolableSize && !this.free.isEmpty()) {
// 如果有线程正好释放掉了,那就直接从free弹出来一个
buffer = this.free.pollFirst();
// accumulated也得标记一下拿到了
accumulated = size;
} else {
// free不够,但是总剩余够了,先释放掉free里的
freeUp(size - accumulated);
int got = (int) Math.min(size - accumulated, this.nonPooledAvailableMemory);
// 剩余的先扣除掉
this.nonPooledAvailableMemory -= got;
// 标记一下,拿到了需要的容量
accumulated += got;
}
}
// Don't reclaim memory on throwable since nothing was thrown
//重置为0
accumulated = 0;
} finally {
// When this loop was not able to successfully terminate don't loose available memory
//异常情况每分出去,准备好的要加回去,如果每一场的话accumulated是0
this.nonPooledAvailableMemory += accumulated;
//把放在队列的条件变量弹出去,该下一个条件变量准备分配了
this.waiters.remove(moreMemory);
}
}
} finally {
// signal any additional waiters if there is more memory left
// over for them
try {
//要是现在剩余容量没了那也别费劲signal下一个了,继续阻塞着吧
//这样会不会导致其他阻塞线程一直等下去呢?不会,因为归还的时候也会signal的
if (!(this.nonPooledAvailableMemory == 0 && this.free.isEmpty()) && !this.waiters.isEmpty())
this.waiters.peekFirst().signal();
} finally {
// Another finally... otherwise find bugs complains
lock.unlock();
}
}
if (buffer == null)
return safeAllocateByteBuffer(size);
else
return buffer;
}
deallocate
还实在是没啥可解析的,简单点。
- 别忘加锁,多线程环境下不加锁肯定池子要泄露的。
- clear清空,如果size和poolableSize相等的话先不释放掉放在free队列里,万一下次有申请的直接复用了不需要初始化,如果不相等的话nonPooledAvailableMemory直接容量加回去就好了调用方会把引用指向null,虚拟机会回收的。
- 通知在等待的线程,如果都是大容量的申请这里是个公平队列哈先来的先分配,后来的后分配。
- 解锁别忘了。
public void deallocate(ByteBuffer buffer, int size) {
lock.lock();
try {
if (size == this.poolableSize && size == buffer.capacity()) {
buffer.clear();
this.free.add(buffer);
} else {
this.nonPooledAvailableMemory += size;
}
Condition moreMem = this.waiters.peekFirst();
if (moreMem != null)
moreMem.signal();
} finally {
lock.unlock();
}
}
结束
卧槽有点累了,这节分个上下吧,CopyOnWriteMap下节讲。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。