UE4内存池浅析[6]——Unreal Engine Binned2 内存分配器深度解析

“仅凭地址即可释放”的经典设计（UE4时代的性能王者，至今仍广泛用于移动端）

Binned2 的设计背景：为何需要它？

在实时渲染引擎中，绝大多数内存操作都集中在小对象上。统计表明，超过90%的内存分配大小不超过32KB，包括 UObject、组件、TArray 元素、FName 以及各类临时容器等。这些对象每帧被频繁创建和销毁，分配/释放次数可达数万甚至数百万次。

若直接依赖系统原生的 malloc/free：

• 多线程环境下会引发全局锁竞争，尤其在高核心数CPU下性能急剧下降；
• 长期运行易产生严重外部碎片，导致几十GB物理内存实际可用率不足60%；
• 单次分配延迟通常在200~1000纳秒之间，难以满足实时性要求。

虽然 Binned1 已通过“41个固定尺寸抽屉 + 64KB内存池”机制有效缓解了碎片问题并提升了速度，但仍存在一个关键缺陷：

void* Ptr;
SIZE_T Size;
Free(Ptr, Size); // 必须显式传入Size！

这在C++开发中极不自然，且容易因误传尺寸导致崩溃或内存损坏。

Binned2 的突破：从“带尺放行”到“见址即释”

诞生于2014至2015年左右（约UE4.8版本），Binned2 实现了一项重要进化：支持无尺寸释放。

void FMallocBinned2::Free(void* Ptr); // 无需Size —— 只看地址就能还原原始大小

这一能力极大简化了使用逻辑，提高了安全性和效率，成为其广受青睐的核心优势。

核心技术原理：全局哈希桶表 + 冲突链结构

Binned2 在原有Binned架构基础上引入了一个“全局退货登记簿”——PoolHashBucket，使得在释放时能根据指针地址反查出其所属的Bin类别，从而定位大小。

1. 全局哈希表的数据结构（共2048个桶）

采用经典的哈希桶设计，每个桶记录对应内存块的信息：

struct FPoolHashBucket
{
    uint16 TableIndex;     // 所属Bin编号（0~40，对应41种BlockSize）
    uint16 Pad;
    FPoolHashBucket* Next; // 用于处理冲突的链表指针（64位平台特有）
};

static FPoolHashBucket PoolHashBuckets[2048];  // 2^11 = 2048 个桶

总内存开销约为16KB（32位）至32KB（64位），占用极小。在64位系统中，当发生哈希冲突时，通过动态new新节点构建链表解决碰撞问题。

2. 分配阶段：写入登记信息

每次调用 Malloc 时，除了常规的内存切分外，还需将该地址信息注册进全局哈希表：

void* FMallocBinned2::Malloc(SIZE_T Size, uint32 Alignment)
{
    // 步骤一：查找对应的Bin索引（0~40）
    uint32 BinIndex = FindBin(Size);               // 查阅预定义的 MemSizeToPoolTable 数组

    // 步骤二：从对应Bin的内存池中分配一块内存
    void* Ptr = AllocateBlockFromBin(BinIndex);

    // 步骤三：关键步骤 —— 将地址信息登记入全局哈希表
    uint64 Address = (uint64)Ptr;
    uint32 Hash = (Address >> 6) & 0x7FF;          // 提取地址中间11位作为哈希索引（范围0~2047）
    FPoolHashBucket* Bucket = &PoolHashBuckets[Hash];

    // 若当前桶已被占用，则沿冲突链向下寻找空位
    while (Bucket->TableIndex != 0xFFFF)           // 0xFFFF 表示无效/空闲条目
    {
        if (!Bucket->Next) 
            Bucket->Next = new FPoolHashBucket();   // 动态扩展冲突链
        Bucket = Bucket->Next;
    }

    // 填写归属信息
    Bucket->TableIndex = (uint16)BinIndex;         // 标记此地址属于哪个Bin
    return Ptr;
}

3. 释放阶段：神级 Free —— 仅凭地址完成回收

Free 操作不再需要用户传入 Size，而是通过地址自动推导：

void FMallocBinned2::Free(void* Ptr)
{
    if (!Ptr) return;

    uint64 Address = (uint64)Ptr;
    uint32 Hash = (Address >> 6) & 0x7FF;           // 使用相同哈希算法定位主桶
    FPoolHashBucket* Bucket = &PoolHashBuckets[Hash];

    while (Bucket)
    {
        if (Bucket->TableIndex != 0xFFFF)
        {
            // 二次验证：确认该地址确实落在目标Bin所管理的虚拟内存区间内
            if (AddressInPoolRange(Address, Bucket->TableIndex))
            {
                // 验证通过，获取原始BinIndex，执行归还流程
                DeallocateBlockToBin(Ptr, Bucket->TableIndex);
                return;
            }
        }
        Bucket = Bucket->Next; // 继续遍历冲突链
    }

    // 未找到匹配项，可能是系统堆分配或其他异常情况
    HandleInvalidFree(Ptr);
}

通过这种“主桶+链表”的双重结构，既保证了快速定位，又具备良好的冲突处理能力，实现了高效、低开销的无尺寸释放机制。

为什么几乎不可能出现误判？

每个 Bin 对应的所有 Pool 都被分配在独立的虚拟内存段中，这些内存区域连续且高达数 GB，彼此之间完全没有重叠。即便发生哈希冲突，也可以通过二次范围校验彻底排除错误匹配的情况，确保 100% 的准确性。

在最坏情况下，冲突链长度也小于 15（基于 2048 个桶和优良的哈希分布），查找效率依然极高。

[此处为图片1]

Binned2 实际性能表现（2025 年移动端实测数据）

代码逻辑如下：

uint32 BinIndex = Bucket->TableIndex;
uint32 BlockSize = BlockSizes[BinIndex];
// 已获取原始大小，归还至对应 Pool
ReturnBlock(Ptr, BlockSize);
return;
}
}
Bucket = Bucket->Next;  // 继续遍历冲突链
}

甘蔗店的终极进化：退货柜台正式上线

如今顾客退货不再需要说明重量，“直接扔甘蔗”即可完成操作：“退！”

店员查看地址信息 → 快速心算 → 取高位 11 位 → 定位到第 1532 号铁桶 → 沿着悬挂的铁钩链条翻找记录纸条 → 确认“属于 1 斤抽屉”

随即冲向对应抽屉，将队列前端甘蔗编号加一；若该尺寸库存恢复可用，则将其移回“有货暗格”。

整个流程耗时仅 20~50ns，顾客纷纷感叹：“这家虚幻甘蔗店，购买迅速，退货更神速，彻底告别排队时代！”

[此处为图片2]

Binned2 的行业地位与影响

• 2015 至 2023 年间，作为 UE4 的核心内存管理方案，在移动端沿用至今——Binned3 因虚拟内存开销过大未能全面替代。
• 确立了“仅凭指针即可完成释放”的行业范式，后续 jemalloc 与 tcmalloc 均借鉴了此类设计理念。
• 截至 2025 年，仍在 Android、iOS、Switch 及 VR 项目中广泛使用，表现强劲。

未来展望：下一代 Binned3 引入“黄金算盘 + 多级抽屉 + 店员巨型腰包”架构，将分配速度从 15ns 提升至 8ns，内存利用率由 92% 提升至 96% 以上。但这已是后话。

Binned2，作为一段不朽的经典，牢牢占据移动端内存管理的王者之位。