OceanBase 内存管理实战指南：多租户内存分配接口、ObMemAttr 标记体系与 Arena/栈安全编程范式

OceanBase 内存管理实战指南：多租户内存分配接口、ObMemAttr 标记体系与 Arena/栈安全编程范式

【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase

OceanBase 作为面向多租户场景的分布式数据库，其内存管理在普通 C++ 工程的基础上叠加了租户级资源隔离与统计的需求，复杂度显著更高。本文以仓库文档 memory.md 为主体，结合 oblib 下的源码实现，系统讲解ob_malloc/OB_NEWx/ObArenaAllocator等常用分配接口、ObMemAttr内存标记体系、reset/reuse对象复用约定，以及SMART_VAR/SMART_CALL两类栈安全编程工具。读完本文，你将掌握 OceanBase 内存分配的选型原则、各接口的底层工作原理，以及如何在多租户环境中正确读写内存统计与配置预留内存。

为什么 OceanBase 的内存管理比普通 C++ 工程更复杂

内存管理是所有大型 C++ 工程中最关键的模块之一，而 OceanBase 还必须额外处理多租户内存资源隔离问题，因此设计复杂度远超普通工程。一个良好的内存管理模块需要同时满足三个维度的诉求：

• 易用：接口必须易于理解和使用，否则代码会难以阅读和维护，也更容易埋下内存错误隐患；
• 高效：分配器性能对整体性能影响重大，尤其在高并发场景下，分配路径必须足够快；
• 诊断：随着代码量增长，内存泄露、越界、野指针等 BUG 在所难免，内存管理模块需要内建辅助排查与避免这类问题的能力。

多租户模式进一步对内存管理提出了两点额外要求：

• 透明的接口设计：让开发人员无感、或极少关心不同租户的内存管理工作，由框架自动按租户记账；
• 高效准确：内存充足时申请必须成功，租户内存耗尽时要能及时察觉——这是多租户内存管理最基础的条件。

围绕这些目标，OceanBase 在 oblib 内存分配模块 中实现了从全局分配器、租户上下文分配器到 Arena 分配器的一整套体系，并在 deps/oblib/src/lib/allocator 中封装了面向业务开发的高层接口。

ob_malloc / ob_free / ob_realloc：libc 风格的租户感知分配接口

OceanBase 自研了一套 libc 风格的内存接口ob_malloc/ob_free/ob_realloc。它们的核心特点是：分配时会根据tenant_id、ctx_id、label等属性动态申请内存，并为内存块打上归属标记。这不仅服务了多租户的资源管理，也为内存问题诊断提供了关键线索。接口声明如下（定义见 ob_malloc.h）：

inline void *ob_malloc(const int64_t nbyte, const ObMemAttr &attr = default_memattr); inline void ob_free(void *ptr); inline void *ob_realloc(void *ptr, const int64_t nbyte, const ObMemAttr &attr);

底层调用关系清晰可查：ob_malloc经由全局单例lib::ObMallocAllocator::get_instance()的alloc(nbyte, attr)完成分配，失败时打印带attr与nbyte的告警日志；ob_free在分配器初始化后调用allocator->free(ptr)归还内存。

三个接口的语义差异需要特别注意：

• ob_malloc：根据tenant_id、ctx_id索引到对应的ObTenantCtxAllocator（租户上下文分配器），由该分配器按照当前租户的上下文环境分配内存；
• ob_free：通过偏移运算求出待释放内存所对应的对象分配器，再把内存放回内存池。因此用户侧无需记住申请时的属性，指针本身即携带归属信息；
• ob_realloc：与 libc 的realloc不同，它不是在原地址上扩容，而是先通过ob_malloc+memcpy将数据复制到一块新内存上，再调用ob_free释放原有内存。这一设计牺牲了部分扩容性能，但保证了租户记账与标记体系的完整性。

ObMalloc类（ob_malloc.h）将该套接口包装成ObIAllocator接口的实现，业务代码可以通过set_label/set_attr设置属性后直接使用。

OB_NEWx 系列宏：带构造/析构的 C++ 风格分配

与ob_malloc类似，OB_NEW提供了一套 "C++" 风格的接口，在分配释放内存的同时会调用对象的构造与析构函数。仓库中的宏定义（ob_malloc.h）包括：

OB_NEW(T, label, ...) // 用 ob_malloc 分配 sizeof(T)，再 placement new 构造 OB_NEW_ALIGN32(T, label, ...) // 按 32 字节对齐分配 OB_NEWx(T, pool, ...) // 从指定 pool（任意 ObIAllocator）中分配 OB_NEW_ARRAY(T, pool, count) // 从 pool 分配数组并构造 OB_DELETE(T, label, ptr) // 先调用析构，再 ob_free OB_DELETEx(T, pool, ptr) // 先调用析构，再归还给 pool

其中OB_NEWx的pool参数可以是任意实现了ObIAllocator的分配器（如后文的ObArenaAllocator），这一模式在 OceanBase 代码中大量使用，例如PageArena::set_tracer中tc_ = OB_NEWx(TracerContext, pool)（见 page_arena.h）。配套的ob_delete<T>(ptr)模板函数（ob_malloc.h）则完成"析构 + 释放 + 置空"的收尾工作。

ObArenaAllocator：多次申请、一次释放的 Arena 分配器

ObArenaAllocator是 OceanBase 中最常用的高性能分配器，其设计特点是多次申请、一次释放：只有调用reset或析构时内存才真正释放，在此之前申请的内存即使主动调用free也不会有任何效用。

它适用于"很多小内存申请 + 短时间后整批释放"的场景。典型例子是一次 SQL 请求：处理过程中会频繁申请大量小内存，而这些小内存的生命周期贯穿整个请求，同时单次 SQL 处理时间通常很短。这种"整体分配、整体回收"的模式对小内存场景极其高效，也天然规避了内存泄露。因此文档特别提醒：在 OceanBase 代码中如果遇到"只看到申请、找不到释放"的代码，不必惊讶——很可能就是 Arena 语义。

源码实现要点

ObArenaAllocator定义于 page_arena.h，内部封装了模板类PageArena：

• 分页机制：内存以 Page 为单位从底层分配器获取，默认页大小DEFAULT_PAGE_SIZE为 8KB（OB_MALLOC_NORMAL_BLOCK_SIZE - sizeof(Page)），超过单页容纳能力的"大块"走alloc_big，其默认大页大小为 2M（OB_MALLOC_BIG_BLOCK_SIZE），见 page_arena.h；
• 分配路径：常规分配在cur_page_上顺序 bump 指针（alloc_end_），页内剩余空间不足时通过extend_page复用链表中的下一页或新申请一页；还有alloc_down（从页尾向下分配）、alloc_aligned_bf（best-fit 对齐分配）等变体；
• free 是空操作：ObArenaAllocator::free被标记为 deprecated，直接忽略参数；正确的回收入口是clear()（等价于arena_.free()）、reset()、reset_remain_one_page()或reuse()；
• reuse 语义：reuse()会释放所有大页（free_large_pages）后复用普通页；fast_reuse()则完全不动底层内存，仅把alloc_end_重置到页首，是最轻量的复用方式；
• Tracer 快照：set_tracer()/revert_tracer()支持记录一个分配快照并回滚到该快照，适合"每轮重复分配再整体释放"的循环场景（page_arena.h）。

PageArena还提供两个实用别名：CharArena（PageArena<>）与ByteArena（PageArena<unsigned char>）。对于多线程共享 Arena 的场景，可以套上ObSafeArenaAllocator（内部以自旋锁保护 alloc/clear/reuse，见 page_arena.h）。

ObMemAttr：一段内存的"身份证"

OceanBase 使用ObMemAttr来标记一段内存的完整归属信息。其定义位于 alloc_struct.h：

struct ObMemAttr { uint64_t tenant_id_; // 租户 ObLabel label_; // 标签、模块 uint64_t ctx_id_; // 参考 ob_mod_define.h，每个ctx id都会分配一个ObTenantCtxAllocator uint64_t sub_ctx_id_; // 忽略 ObAllocPrio prio_; // 优先级 };

参考文件 alloc_struct.h

需要说明的是，当前仓库源码中的ObMemAttr实际还包含numa_id_以及一组位域标志（use_500_、expect_500_、ignore_version_、enable_malloc_hang_）与extra_size_，用于内存版本管理与 500 错误场景等高级控制；sub_ctx_id_在文档对应的接口版本中已被忽略。构造函数的默认参数为tenant_id = common::OB_SERVER_TENANT_ID、label为空、ctx_id = 0、prio = OB_NORMAL_ALLOC。

tenant_id：租户维度记账

内存分配管理会按照租户维护资源统计与限制。同一段物理内存会被精确归属到某个租户名下，从而支撑多租户的限额与回收策略。

label：模块标签

早期 OceanBase 使用预定义方式为各个模块创建内存标签（预定义列表见 ob_mod_define.h 中的LABEL_ITEM_DEF宏，涵盖 SQL、事务、存储、RootService、liboblog 等数百个模块）。但随着代码量增长，预定义标签难以覆盖所有场景，当前已改为直接使用常量字符串构造ObLabel。在使用ob_malloc时可以直接传入常量字符串作为ObLabel参数。

从源码看，ObLabel（alloc_struct.h）内部仅保存一个const char *str_指针，并约束标签长度不得超过 15 个字符（AOBJECT_LABEL_SIZE = 15，超长会在编译期触发STATIC_ASSERT）。预定义标签的字符串值存储于ObModIds，其数量有硬性上限检查：STATIC_ASSERT(LABEL_COUNT_LIMIT == 454, "forbidden to add new label!!!")（ob_mod_define.h），可见标签体系是受控管理的。

ctx_id：分配上下文

ctx_id是预定义的，完整枚举见 ob_mod_define.h 的CTX_ITEM_DEF列表。每个租户的每个ctx_id都会创建一个ObTenantCtxAllocator对象，可以独立统计该上下文的内存分配情况。常用取值包括：

• DEFAULT_CTX_ID：通常情况下使用的默认上下文；
• GLIBC：glibc 直接分配的内存；
• CO_STACK：协程栈；
• LIBEASY：libeasy 通讯库；
• LOGGER_CTX_ID、PKT_NIO、SCHEMA_SERVICE：日志、网络包、Schema 服务等；
• UNEXPECTED_IN_500：异常路径（500）兜底上下文；
• 以及PLAN_CACHE_CTX_ID、WORK_AREA、MEMSTORE_CTX_ID、TRANS_CTX_MGR_ID、VECTOR_CTX_ID、DDL_KV_CTX_ID等业务上下文。

一些特殊模块（如 libeasy 通讯库、Plan Cache）会使用专属ctx_id，以便更直观地观察内存使用、更方便地排查问题。我们可以在运行日志中看到周期性的内存统计信息，例如：

[2024-01-02 20:05:50.375549] INFO [LIB] operator() (ob_malloc_allocator.cpp:537) [47814][MemDumpTimer][T0][Y0-0000000000000000-0-0] [lt=10] [MEMORY] tenant: 500, limit: 9,223,372,036,854,775,807 hold: 800,768,000 rpc_hold: 0 cache_hold: 0 cache_used: 0 cache_item_count: 0 [MEMORY] ctx_id= DEFAULT_CTX_ID hold_bytes= 270,385,152 limit= 2,147,483,648 [MEMORY] ctx_id= GLIBC hold_bytes= 8,388,608 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= CO_STACK hold_bytes= 106,954,752 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= LIBEASY hold_bytes= 4,194,304 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= LOGGER_CTX_ID hold_bytes= 12,582,912 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= PKT_NIO hold_bytes= 17,969,152 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= SCHEMA_SERVICE hold_bytes= 135,024,640 limit= 9,223,372,036,854,775,807 [MEMORY] ctx_id= UNEXPECTED_IN_500 hold_bytes= 245,268,480 limit= 9,223,372,036,854,775,807

解读要点：首行tenant: 500为租户 ID，limit为该租户内存上限，hold为当前占用；随后每个ctx_id一行，hold_bytes是该上下文当前占用，limit是该上下文限额（DEFAULT_CTX_ID行显示其 limit 有实际限额，而多数专用上下文 limit 为极大值，表示不单独设限）。这段日志对应的输出逻辑位于 ob_malloc_allocator.cpp 附近的MemDumpTimer周期性任务。

prio：分配优先级

当前支持两个内存分配优先级，定义于 alloc_struct.h：

enum ObAllocPrio { OB_NORMAL_ALLOC, // Normal，默认 OB_HIGH_ALLOC // High };

默认为Normal。高优先级内存可以从 urgent（memory_reserved）内存中分配内存，否则不可以，其判定逻辑参考AChunkMgr::update_hold的实现。相应接口包括ob_set_urgent_memory与ob_get_reserved_urgent_memory（见 alloc_func.h）。

可以使用配置项memory_reserved查看预留内存大小。该配置决定了系统为关键路径（如日志、异常处理）预留的紧急内存额度，避免内存耗尽时连错误处理都无法进行。

init / destroy / reset / reuse：对象生命周期的约定俗成

缓存是提升程序性能的重要手段，对象重用也是缓存的一种方式：一方面减少内存申请与释放的频率，另一方面减少构造析构的开销。OceanBase 中大量使用对象重用，并形成了init/destroy/reset/reuse的接口约定：

• init / destroy：对象初始化与销毁。构造函数中仅做轻量级初始化（例如把指针初始化为nullptr），真正的资源获取放在init中，资源释放放在destroy中，以便配合对象池复用；
• reset：重置对象，把对象状态恢复成构造函数或init执行后的状态，例如ObNewRow::reset；
• reuse：相较于reset更加轻量，尽量不去释放一些开销较大的资源，例如PageArena::reuse。在 page_arena.h 中可以看到reuse()先释放大页再调用fast_reuse()，而fast_reuse()仅把alloc_end_指回页首并清零used_统计，底层页完全不归还给操作系统。

这套约定让对象池、Arena、缓存等组件可以在"复用状态"与"全新状态"之间高效切换，是 OceanBase 高性能内存路径的重要基石。

SMART_VAR / HEAP_VAR：平衡栈内存与性能的局部变量助手

SMART_VAR是定义局部变量的辅助接口，使用该接口的变量总是优先从栈上分配，当栈内存不足时退化为从堆上分配。对于那些不易优化的大型局部变量（>8K），该接口既保证了常规场景的性能，又能把栈容量安全地降下来。接口定义如下：

SMART_VAR(Type, Name, Args...) { // do... }

其栈上分配的判定条件为：

sizeof(T) < 8K || (stack_used < 256K && stack_free > sizeof(T) + 64K)

即：类型小于 8K 时直接栈上分配；否则要求当前线程栈已用量低于 256K、且栈剩余空间大于"对象大小 + 64K"的安全余量，才在栈上分配，否则转入堆分配。宏定义位于 ob_smart_var.h，源码中还扩展了SMART_VAR_INDEPENDENT、SMART_VARS_2/3/4（多变量版本）等变体。

SMART_VAR的出现是为了解决历史问题：尽量减少大内存对象占用太多栈内存。仓库代码中可见大量实际用例，例如 ob_malloc_allocator.cpp 中SMART_VAR(char[BUFLEN], buf)用于拼接内存统计输出，ob_mysql_connection.cpp 中SMART_VAR(char[OB_MAX_SQL_LENGTH], sql)用于构造 SQL 语句。

HEAP_VAR与SMART_VAR类似，只是它一定会在堆上申请内存，适用于明确不想占用栈空间的场景。

SMART_CALL：准透明化解栈溢出的递归调用

SMART_CALL用于"准透明化"地解决那些在栈非常小的线程上可能爆栈的递归函数调用。它接受一个函数调用作为参数，在函数调用前自动检查当前栈的使用情况，一旦发现栈可用空间不足，立即在本线程上新建一个栈执行函数，函数结束后继续回到原始栈——既保证了栈足够时的性能，也能兜底爆栈场景。

SMART_CALL(func(args...))

宏定义位于 ob_smart_call.h。使用时需要遵守三条约定：

1. func 的返回值必须是表征错误码的 int 类型；
2. SMART_CALL会返回错误码，这个错误码可能是内部机制的（如栈溢出检测失败），也可能是 func 调用的；
3. 支持栈级联扩展，每次扩展出一个 2M 栈，并有一个写死的总上限10M。

SMART_CALL相对于直接调用，多了一次check_stack_overflow栈溢出检查的开销。正因为有了这套机制，OceanBase 才能在栈容量受限的租户线程中安全地执行深度递归的表达式求值、JSON 解析等逻辑。

小结：如何选型与自查

综合以上接口，OceanBase 内存分配的选型原则可以归纳为：

自查清单：新代码中申请的内存是否打上了正确的tenant_id/label/ctx_id？对象复用时是选择昂贵的reset还是轻量的reuse？超过 8K 的栈上大对象是否应该改用SMART_VAR？这些细节共同决定了 OceanBase 在多租户、高并发下的内存效率与可诊断性。

【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase