系列01：内存管理——当你在管理 ByteBuf 时，你已经在管理 KV Cache 了
这篇讲什么 这是个系列的第一篇。我选"内存管理"作为开篇，因为： 你最熟——Netty ByteBuf、JVM 堆、堆外内存，你每天都在打交道 映射最直接——ByteBuf 池化 = KV Cache Block 管理 = GPU 显存池 代码最少——核心逻辑 100 行就能说清原理 读完这篇，你会理解： ByteBuf 的引用计数为什么等于 vLLM Block 的 refcount JVM 的 G1 Region 为什么等于 PagedAttention 的 Block GPU 显存池为什么是你的 PooledByteBufAllocator 在另一个地址空间的翻版 并且，你可以亲手写一个"Java 版显存管理器" 一、问题本质 内存管理要解决的只有三个问题： 1. 分配——如何快速找到一块可用的内存 2. 回收——用完后如何归还，确保不漏 3. 碎片——如何避免小块空隙越积越多 你在 Java 后端看到过这些方案的演进： JVM 堆管理： Serial GC → 标记-整理（压缩碎片） CMS → 标记-清除（不压缩，碎片多） G1 → Region 分区（固定大小，消除碎片） ZGC → 染色指针 + 读屏障（几乎无停顿） Netty 堆外内存管理： UnpooledByteBufAllocator → 每次分配新 DirectBuffer PooledByteBufAllocator → 预分配 Arena + Chunk + Page 分三级管理 AI Infra 的显存管理（正在发生和你一模一样的事情）： PyTorch 默认（CUDACachingAllocator）→ 有缓存但碎片严重 vLLM PagedAttention → Region 分块（和 G1 一样的思路） 这不是类比，这是同一个问题在不同约束下的工程演化。 ...