MetaSpace的Chunk Allocation是按需分配SpecializedChunk（约4KB）、SmallChunk（约64KB）、MediumChunk（约4MB）等不同大小内存块的机制，类加载器从其SpaceManager中获取Chunk并在其中线性分配元数据。

方法区在 JDK 8+ 中由元空间（Metaspace）实现，而类元数据的物理存储并非连续大块内存，而是通过分层、按需分配的 MetaChunk（元块）机制组织管理。它的核心逻辑是：**以类加载器为单位，按需申请不同粒度的内存块，在块内线性分配元数据，同时复用空闲块降低系统开销。**

类加载器与 MetaChunk 的绑定关系

每个类加载器（Bootstrap、Platform、Application 或自定义）在首次定义类时，会向全局 ChunkManager 申请一个初始 MetaChunk，并将该块逻辑上“绑定”到自身生命周期。这种绑定不是强引用式独占，而是管理归属——即该加载器后续所有类元数据都优先从自己名下的 Chunk 中分配。

• 同一加载器可持有多个 Chunk（如小类频繁加载时触发多次申请）
• 不同加载器的 Chunk 可能物理上混布在同一 VirtualSpace 节点中，但逻辑归属清晰
• 加载器被 GC 回收时，其全部关联 Chunk 才会被整体标记为空闲，归还至 ChunkManager 全局池

MetaChunk 的三级尺寸策略

JVM 不统一按固定大小分配，而是根据元数据体量预设三类典型 Chunk 尺寸，兼顾空间效率与分配速度：

• SpecializedChunk：约 1KB–4KB，专用于极小元数据（如空接口、极简枚举）
• SmallChunk：约 64KB，最常用，覆盖绝大多数普通类的字段、方法、常量池等元数据
• MediumChunk：约 4MB，用于大型类（如含大量注解、泛型嵌套或巨量静态字段的类）
• LargeChunk（极少使用）：超过 4MB，仅在极端场景下触发

选择哪一类由 SpaceManager 根据当前类元数据估算大小后决策，避免小类浪费大块，也防止大类频繁切块。

底层内存来源：VirtualSpaceList 与本地内存

所有 MetaChunk 的物理内存均来自操作系统本地内存（Native Memory），而非 Java 堆。JVM 底层通过 mmap（Linux/macOS）或类似机制，按 2MB 对齐的“虚拟空间节点（VirtualSpace node）”向 OS 预留大块地址空间；实际使用时再按需提交（commit）页面。

• 这些节点组成全局链表 VirtualSpaceList，每个节点维护自己的“已提交水位线”
• Chunk 分配不直接触碰 OS，而是在已提交的 VirtualSpace 内部切分 MetaChunk
• 因此 Metaspace 占用的 committed 内存可能远大于 used，尤其在卸载不彻底时形成“假性碎片”

为什么不能靠 GC 清理碎片？

MetaChunk 的回收不依赖常规垃圾收集器（GC）触发，它完全跟随类加载器的生命周期：

• 只要一个类加载器仍被强引用，它持有的所有 Chunk 就不可释放
• 即使其中部分类已被卸载，只要 Chunk 内还有其他存活类元数据，整个 Chunk 就继续占用
• System.gc() 或任何堆 GC 操作对 Metaspace 内存无直接影响
• 真正的释放只发生在类加载器对象被 GC 回收后，由 JVM 后台线程批量归还其全部 Chunk 到 ChunkManager