想象你是一家热门餐厅的主厨。如果每做一道菜，你都不辞辛劳跑去菜市场买一把葱、一块肉，再气喘吁吁跑回来，你会把一整天都耗在路上——这正是程序频繁调用操作系统内存分配的写照：每次向系统申请内存，都要经历权限切换、空闲块查找、加锁等待，开销高得吓人。 内存池就像一个“备菜库”：开业之前，你一次性采购大批常用食材，分门别类放到货架上；做菜时随手取用，用完洗净放回原处。整个过程，你只需要在备菜库和灶台之间往返，再也不用跑菜市场。这不仅把“每次买菜”变成了“一次囤货”，还能把货架空间安排得明明白白。在 AI 编译器与系统软件的世界里，张量、激活值、梯度就像流水线上一批批进出的食材。掌握内存池管理，就是学会给这条流水线设计一座高效的备菜库。

岗位关联

内存池是 AI 编译器高性能推理与训练的生命线。掌握它，你的模型部署才能既快又省，面试和工程实战都多一张王牌。

目录
  1. 可视化演示
  2. 内存池原理
  3. 分配器设计
  4. 碎片管理
  5. 性能特性
  6. 优化策略
  7. AI 编译实战
  8. 常见问题
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示内存池预分配与O(1)指针偏移分配机制、张量生命周期图着色复用算法及静态动态内存池碎片对比三种核心模式，直观呈现AI编译器内存池优化技术。

本节配有交互动效（进入视口后自动加载，约 3KB）。

内存池分配过程 预分配连续内存区域按需O(1)指针偏移分配 释放后块立即被新分配复用消除碎片 Utilization = Used_Blocks / Total_Blocks 内存池避免频繁malloc/free开销

内存池原理

主厨开店的第一个决定，是去菜市场“梭哈”一次：买回一车食材，而不是每道菜都跑一趟。内存池的原理正是如此。程序启动时，内存池向操作系统一次性申请一大块内存——这就是“整块大块申请”；随后把它切成固定大小的块，放进备菜库的货架——这是“预分配思想”。此后所有小对象的分配都不再求助于系统，而是从货架上直接取。

这里的关键在于“对象循环复用”。传统方式每次分配都走系统调用，好比每道菜都跑菜市场，来回折腾还堵车；而内存池把归还的块重新挂回空闲链表，下次分配直接拿走，整个生命周期只和备菜库打交道。池化收益的本质，是把高频的小额交易，换成一次大额批发加无数次零成本取用。

回到餐厅来理解：备菜库最大的功劳不是把菜变新鲜，而是把主厨的时间从“跑腿”中解放出来。内存池亦然——它把 CPU 从频繁的内核态切换中解放出来，让分配真正成为一件“顺手的事”。

Tpool(n)=Tpre+n×tget,Tdirect(n)=n×(tcall+tlock)\displaystyle T_{\text{pool}}(n) = T_{\text{pre}} + n \times t_{\text{get}}, \qquad T_{\text{direct}}(n) = n \times (t_{\text{call}} + t_{\text{lock}})
公式对比了分配 n 个对象的总开销：内存池只付一次过路费，之后每次都是“伸手就取”；直接分配则每取一次都要交系统调用和锁的“过路费”。
  1. 预分配固定开销T_pre 是内存池初始化时向系统申请大块内存的一次性成本，包含一次系统调用的开销，与 n 无关。
    TpreT_{\text{pre}}
  2. 池内取块边际成本n × t_get 表示从备菜库取 n 次食材的总耗时，t_get 只是移动链表指针的几纳秒操作。
    n×tgetn \times t_{\text{get}}
  3. 直接分配的累计成本n × (t_call + t_lock) 中，t_call 是每次系统调用的开销，t_lock 是并发场景下分配器锁的等待时间，二者叠加后随 n 线性增长。
    n×(tcall+tlock)n \times (t_{\text{call}} + t_{\text{lock}})

分配器设计

备菜库内部怎么摆货架，决定了厨师取料快不快。三种经典设计各有各的巧思。Free List（空闲链表） 是最朴素的“待用食材篮”：所有空闲块用链表串起来，取用时从链表头摘下，归还时插回链表头，先来后到，O(1) 完成。Buddy 伙伴系统 像一组可拆分的标准储物箱：所有箱子按 2 的幂分档，大块可以一分为二，两块相邻的孪生箱子空闲时又能合二为一。Slab 分片 则是给特定食材（比如张量描述符这类定长对象）预留的专属柜格，种类固定、布局紧凑，连链表都省了。

Buddy 系统最精妙的是“找伙伴”只需一次异或运算。假设当前块地址为 p，它属于第 k 级（即每块大小为 2^k 个基本单元），那么它的伙伴块地址可以秒算出来：

三种货架各司其职：小尺寸高频率的对象交给 Free List 最轻快；需要动态伸缩的大块交给 Buddy 最灵活；定长热对象用 Slab 最省心。现实中，成熟的内存池往往把三者组合，如同一个厨房既有小料篮，又有可拼拆的储物箱，还有调料专属柜。

b=p⊕2k\displaystyle b = p \oplus 2^{k}
这个公式是 Buddy 系统的“寻亲图”：只要知道自己的地址和级别，XOR 一下就能找到隔壁那格是不是自家兄弟，从而决定能否合并。
  1. 当前块地址p 表示内存池中某个块的起始地址（可理解成货架格子的编号位串）。
    pp
  2. 级别基址2^k 是当前块所在档位的尺寸，表示该块由 2^k 个最小单元组成，例如 2^3 = 8 表示 8 格一箱。
    2k2^{k}
  3. 异或运算XOR 运算将 p 的第 k 位翻转。由于伙伴块恰好是“同档位、相邻、一左一右”，所以翻转这一位就能直达伙伴地址。
    p⊕2kp \oplus 2^{k}

碎片管理

货架用久了，问题就来了。厨师把肉末装进大盘子，盘子剩余空间全浪费了——这叫内部碎片；货架上东一个西一个的空格，单独放不下一块新豆腐，加在一起却能装下一整只鸡——这叫外部碎片。内存池虽然减少了系统调用，却并没有天然消灭碎片。

Buddy 的“伙伴合并”是抗击外部碎片的第一道防线：两个相邻的同档位空闲块，合并成一个更大的档位，让零散空间重新聚拢。但光靠合并还不够，偶尔还需要内存规整——也就是定期理库：把活跃对象往一端搬运，腾出整段连续空间，类似于把散落的食材重新摆齐。

有经验的主厨每周都会理一次库，把散落各处的食材重新归位。内存池也一样：伙伴合并在平时默默工作，内存规整则在关键时刻把“一盘散沙”重新变成“一块整地”。二者配合，碎片才能被真正驯服。

F=1−Lmax⁡Sfree\displaystyle F = 1 - \frac{L_{\max}}{S_{\text{free}}}
碎片率 F 衡量空闲空间的“散乱程度”：F 越接近 0，说明空闲空间越集中、利用率越高；F 接近 1 则说明大量空闲被切得细碎，几乎无法利用。
  1. 最大连续空闲段L_max 表示货架上最长的一段连续空闲格数——这是当前能容纳单个最大对象的极限。
    Lmax⁡L_{\max}
  2. 总空闲量S_free 是所有空闲格数量之和，无论它们是否连续。
    SfreeS_{\text{free}}
  3. 聚合度比值L_max / S_free 表示空闲空间集中程度，若等于 1 说明全部空闲连成一片，利用率最佳。
    Lmax⁡Sfree\frac{L_{\max}}{S_{\text{free}}}
  4. 碎片率定义用 1 减去聚合度得到碎片率，值越大说明外部碎片越严重，越需要合并与规整。
    F=1−Lmax⁡SfreeF = 1 - \frac{L_{\max}}{S_{\text{free}}}

性能特性

备菜库最大的骄傲是“快”。厨师下单，抬手就能取到食材，不用等——这就是 O(1) 分配：无论池里有多少块，取一块和取另一块的时间几乎相同。更妙的是，备菜库紧挨着灶台，食材都在手边，食材之间的位置也彼此紧挨着，CPU 读起来格外顺畅——这叫缓存友好，连续的内存地址能大幅提高 L2/L3 缓存命中率。

多线程场景下，性能的另一大杀手是锁竞争。如果所有厨师都抢一把勺，队伍能排到门口去。内存池的解法是“一个灶台一个小推车”——每个线程维护本地缓存，先从小推车取料，不够了才去大仓库搬。这样绝大多数分配完全不碰全局锁。平均分配耗时可以建模为：

主厨的小推车让“做菜”这件高频动作不再被仓库大门卡住。内存池的线程本地缓存同理：它把锁竞争从每次分配都发生，压缩成偶尔才发生，吞吐量如开闸放水般提升。

tˉ=p×tglobal+(1−p)×tlocal\displaystyle \bar{t} = p \times t_{\text{global}} + (1-p) \times t_{\text{local}}
公式描述“先本地、后全局”的平均耗时：本地取料 10 纳秒，全局搬料 100 纳秒，只要本地命中率够高，平均耗时就被拉得很低。
  1. 本地命中概率p 表示本地小推车没货、需要去全局仓库取的概率；p 越小，说明线程本地池设计越合理。
    pp
  2. 本地取料耗时t_local 是从线程本地池取块的时间，通常只有几条指令，无锁、无系统调用。
    tlocalt_{\text{local}}
  3. 全局兜底耗时t_global 是本地不足、转向全局池时的耗时，包含锁等待或跨线程迁移，通常高一个数量级。
    tglobalt_{\text{global}}
  4. 加权平均整体平均耗时是两者的概率加权和。当 p ≈ 0.1 时，平均耗时贴近 t_local，吞吐量自然飙升。
    tˉ=p×tglobal+(1−p)×tlocal\bar{t} = p \times t_{\text{global}} + (1-p) \times t_{\text{local}}

优化策略

货架怎么摆，还有大学问。大小类映射是最基本的优化：把所有请求的尺寸向上取整到 2 的幂对应的档位，32B、64B、128B……每档一条独立 Free List。这样 100 字节的请求被分到 128B 的柜格，查找时间变成一次计算，而不是遍历整个货架。计算规则简单而优雅：

除了分级，还有三招常用组合拳：线程本地池给每个线程发一辆小推车；阈值切换规定超过某个尺寸（如 256KB）的大块不走池，直接向系统申请——好比整扇猪肉不进备菜库，直接送冷库；动态扩容则是备菜库快空时按批进货，而不是一次只买一根葱。四招齐下，内存池既快又不臃肿。

S=2⌈log⁡2n⌉\displaystyle S = 2^{\lceil \log_2 n \rceil}
公式把一个任意大小的请求“对齐”到不小于它的 2 的幂：100 → 128，正好像把散装食材装进最接近的标准密封袋。
  1. 请求尺寸n 是上层代码实际请求的字节数，例如想申请 100 字节存一个结构体。
    nn
  2. 二进制数量级log2 n 计算 n 的二进制位数数量级，100 的 log2 约为 6.64。
    log⁡2n\log_2 n
  3. 向上取整\lceil 6.64 \rceil 得到 7，保证结果不小于原值，避免柜格装不下。
    ⌈log⁡2n⌉\lceil \log_2 n \rceil
  4. 幂次对齐2^7 = 128，即实际分配类别大小，请求被归入 128B 的 Free List。
    S=2⌈log⁡2n⌉S = 2^{\lceil \log_2 n \rceil}

AI 编译实战

AI 编译器是最需要备菜库的地方。模型推理时，张量像流水线上的食材一样被反复创建、销毁：卷积的输出、激活值、中间结果，每一层都产生新张量。若每次都向系统申请，显存分配器会成为整个执行过程的瓶颈。AI 框架的做法是维护一个张量缓存池：张量销毁时内存不还给系统，而是留在池中，下一个大小合适的张量直接接管——这就是 PyTorch CachingAllocator 的核心思想。

更上游的优化来自图内存规划。AI 编译器在编译阶段就能分析出每个张量的生命周期：哪些张量“死”得早、哪些活得久，把生命周期不重叠的张量安排到同一块内存上复用，像后厨排班一样精确。这个思路直接作用于峰值内存，尤其对端侧部署意义重大——手机内存小，峰值每降 1MB，能多跑一层模型。

备菜库让主厨不再为食材来源分心，AI 编译器的内存池则让算子不再为显存分配分心。从 PyTorch 到 TVM，从训练到端侧推理，内存池 + 静态规划的组合拳，正是大模型能跑在手机上的幕后功臣。

Mpeak=max⁡t∑i: vi(t)=1si\displaystyle M_{\text{peak}} = \max_{t} \sum_{i:\, v_i(t)=1} s_i
公式计算任意时刻所有“存活”张量大小之和的最大值。图内存规划的目标，就是让每个时刻的存活集合尽量小，从而压低峰值。
  1. 张量个体大小s_i 表示第 i 个张量占用的字节数，如一个 1024×1024 的 float32 张量占 4MB。
    sis_i
  2. 存活标记v_i(t)=1 表示张量 i 在时刻 t 仍被后续算子引用；已经“死亡”的张量不占内存，如同用完的食材已下架。
    vi(t)=1v_i(t)=1
  3. 同时刻求和把 t 时刻所有存活张量的大小相加，得到该时刻的内存总占用。
    ∑i: vi(t)=1si\sum_{i:\, v_i(t)=1} s_i
  4. 取最大值遍历所有计算时刻，取占用总和最大者，即为峰值内存 M_peak。
    Mpeak=max⁡t∑i: vi(t)=1siM_{\text{peak}} = \max_{t} \sum_{i:\, v_i(t)=1} s_i

常见问题

备菜库用不好，也会翻车。池膨胀是最常见的坑：仓库越建越大，食材却只用了冰山一角。判断标准很简单：

第二个坑是内存泄漏：食材取走不归还，备菜库总有一天被掏空。内存池只负责加速，不负责替你记住规则——忘记归还的后果同样致命。第三个坑是过度池化：连只有一次性的筷子都要进备菜库，反而让管理开销超过收益。第四个坑是调试困难：内存池把大量对象揉在一起，出错时难以定位是哪个环节写坏了数据。理解这些坑，才能在工程设计时守住边界：池不是万能的，规模、频率、生命周期匹配才是王道。

E=SpoolSused\displaystyle E = \frac{S_{\text{pool}}}{S_{\text{used}}}
池膨胀率 E 是“租的仓库 / 实际用的货架”。如果 E 高达 5，说明你已经为用不到的空间付了 5 倍租金。
  1. 池总容量S_pool 是内存池向系统申请的总字节数，即仓库总面积。
    SpoolS_{\text{pool}}
  2. 实际占用S_used 是当前被业务真正持有并活跃的字节数。
    SusedS_{\text{used}}
  3. 膨胀率E = S_pool / S_used，远大于 1 说明内存闲置严重，应当调小初始预分配或增加池收缩机制。
    E=SpoolSusedE = \frac{S_{\text{pool}}}{S_{\text{used}}}

AI 应用场景

PyTorch 显存缓存池

阶段：模型训练与推理的张量分配

解决的问题：训练中每层算子都产生新张量，直接向 CUDAMalloc 申请显存会频繁触发内核态调用和显存碎片。PyTorch 的 CachingAllocator 预先申请超大块显存，切成大小类缓存，张量释放后留池复用，分配速度提升数十倍。

具体案例：训练 BERT 时，Transformer 的 QKV 矩阵每步前向都会创建和销毁。使用缓存池后，显存申请次数从每秒上万次降到几十次，训练吞吐提升约 20%，且显存碎片明显减少。

端侧推理引擎的内存池

阶段：移动端/嵌入式部署

解决的问题：手机内存仅几 GB，模型推理途中频繁 malloc/free 会引起 heap 碎片和卡顿。NCNN、MNN 等引擎在会话初始化时构建固定大小内存池，按张量形状动态划块，全程零系统调用。

具体案例：某端侧人脸检测模型，初始化时创建 8MB 内存池，推理峰值内存从 34MB 降到 12MB，帧率从 15fps 提到 30fps——因为内存分配不再阻塞计算流水线。

AI 编译器的图内存规划

阶段：编译期静态内存优化

解决的问题：动态分配依赖运行时信息，容易产生峰值浪费。TVM、XLA 在编译期分析张量生存期，把无重叠的张量合并到同一块内存池，将峰值内存压到理论下限。

具体案例：将 ResNet-50 编译为 TVM 后，图内存规划把 218 个中间张量的生存期排布到同一块 6.4MB 内存池，相比 PyTorch 动态模式的 15MB 峰值显存，节省超过 55%。

Python 演示

python72 行
class MemoryBlock:    """内存块节点：记录尺寸与占用状态"""    def __init__(self, size, allocated=False):        self.size = size        self.allocated = allocated  class SizeClassPool:    """大小类内存池：32B / 64B / 128B 三档 Free List，    分配时向上取整映射，池空时动态扩容。"""     def __init__(self):        self.class_sizes = [32, 64, 128]        self.total = 0            # 池总字节数        self.used = 0             # 已用字节数        self.free_lists = {s: [] for s in self.class_sizes}        self.blocks = {s: [] for s in self.class_sizes}        self._expand(4)           # 预分配 4 个 128B 大块     def _round_up(self, size):        """大小类映射：100 -> 128，返回实际分配的档位"""        for s in self.class_sizes:            if size <= s:                return s        raise ValueError('超过 128B 的大对象请走系统分配器')     def _expand(self, unit_count):        """动态扩容：一次性向系统申请 unit_count 个 128B 大块"""        for _ in range(unit_count):            for s in self.class_sizes:                per_chunk = 128 // s                for _ in range(per_chunk):                    idx = len(self.blocks[s])                    self.blocks[s].append(False)                    self.free_lists[s].append(idx)        self.total += unit_count * 128     def allocate(self, size):        """从对应档位 Free List 头取一个空闲块，O(1)"""        s = self._round_up(size)        if not self.free_lists[s]:            self._expand(1)       # 池空则再进一批货        idx = self.free_lists[s].pop()        self.blocks[s][idx] = True        self.used += s        return s, idx     def deallocate(self, size, idx):        """将块归还到对应档位的 Free List 头"""        s = self._round_up(size)        self.blocks[s][idx] = False        self.free_lists[s].append(idx)        self.used -= s     def usage(self):        return self.used / self.total  if __name__ == '__main__':    pool = SizeClassPool()    print('初始化：总容量 %d 字节，占用率 %.2f%%' % (pool.total, pool.usage() * 100))     a = pool.allocate(16)         # 落到 32B 档    b = pool.allocate(50)         # 落到 64B 档    print('分配 a(16B)=%s, b(50B)=%s' % (a, b))    print('占用率 %.2f%%' % (pool.usage() * 100))     pool.deallocate(*a)           # 归还 a    print('释放 a 后占用率 %.2f%%' % (pool.usage() * 100))     c = pool.allocate(30)         # 复用 a 归还的 32B 块    print('再分配 c(30B)=%s，占用率 %.2f%%' % (c, pool.usage() * 100))
目的：用 60 行代码实现一个带大小类映射、预分配和动态扩容的最小内存池，直观展示“一次囤货、随取随还”的核心机制。
  1. self.free_lists = {s: [] for s in self.class_sizes}每一档尺寸独立一条空闲链表，相当于备菜库里不同规格的货架。
  2. self._expand(4)初始化时一次性向系统申请 4 个大块，对应开业前一次性采购。
  3. _round_up` 中的 `for s in self.class_sizes: if size <= s: return s大小类映射的核心：100 字节请求被对齐到 128B 档位。
  4. if not self.free_lists[s]: self._expand(1)档位空时按批扩容，避免频繁跑“菜市场”。
  5. idx = self.free_lists[s].pop()从链表头取块，O(1) 完成分配，正是“伸手就拿”。
  6. self.free_lists[s].append(idx)归还时挂回链表头，分配器不关心对象内容，只管位置。

常见误区

误区预分配得越多，池命中率就越高，所以把池容量设成峰值内存的几倍准没错。

正解池膨胀率 E = 池总容量 / 实际使用量。E 远大于 1 意味着大量内存在闲置，会挤压同一进程里其他模块的空间。正确做法是设定合理的初始容量，配合动态扩容与收缩机制，像备菜库一样“按需进货、淡季退货”。

为何常见：人们只看到预分配减少了系统调用，却忽略了闲置内存同样占用宝贵资源，容易陷入“为了快而浪费”的盲区。

误区既然内存池是自己管理内存，就不会有碎片问题，可以高枕无忧。

正解内存池只是把碎片转移了阵地：向系统申请的大块内部，外部碎片可能变成内部碎片——100 字节的请求分到 128B 格子，28 字节就此浪费。碎片率公式 F = 1 - L_max / S_free 对池内空间同样适用，仍需伙伴合并和内存规整来治理。

为何常见：内存池掩盖了系统层面的碎片，让人误以为所有碎片都消失了，实际上只是从“看得见的坑”变成“看不见的缝”。

误区用了内存池之后，再也不用担心内存泄漏，池子会自动管理一切。

正解内存池只负责加速分配与回收，不负责业务逻辑。如果某段代码取走了块却忘记归还，池的可用块只会越来越少，最终池空崩溃——这比系统泄漏更难排查，因为它不会立刻报错，而是慢慢耗尽。归还规则必须由使用者保证。

为何常见：分配器自动化的印象让人误以为池子自带“记忆”，忽略了池本身只是一个被动的货架。

误区内存池收益这么大，干脆把所有 malloc/free 全换成内存池，一把梭。

正解低频大对象（如加载整个模型权重）走池化收益极低，反而会让池容量暴涨。业界惯例是设阈值：小对象（几十字节到几百 KB）进池，大对象直接走系统分配器。就像备菜库只备常用食材，整扇猪肉直接进冷库，否则仓库会被一件大货占满。

为何常见：看到内存池的性能数据后容易过度推广，忽略了池的适用边界——高频、小对象、生命周期不均才是它的主场。

面试题

Q1. 内存池最核心的优化思路是什么？

单选题 · easy

  • A.每次分配都向操作系统申请新内存
  • B.预先申请大块内存并循环复用← 正确答案
  • C.用虚拟内存完全代替物理内存
  • D.把所有内存块都设为只读权限

答案：B。内存池的本质是“一次囤货、随取随还”：启动时预分配大块内存，对象归还后复用，从而避免每次分配都触发系统调用。A 是传统模式，C、D 与池化无关。

Q2. Free List（空闲链表）取一个空闲块的典型时间复杂度是？

单选题 · easy

  • A.O(n)
  • B.O(log n)
  • C.O(1)← 正确答案
  • D.O(n²)

答案：C。Free List 用链表串起所有空闲块，分配时直接从链表头取出，归还时插回头部，全程只操作指针，不遍历。正如从备菜篮顶拿食材，伸手就是那一格。

Q3. Buddy 系统中，大小为 2^k 的块地址为 p，其伙伴块地址是？

单选题 · mid

  • A.p + 2^k
  • B.p - 2^k
  • C.p XOR 2^k← 正确答案
  • D.p AND 2^k

答案：C。伙伴块与当前块同档位、左右相邻，地址只差第 k 位不同。按位异或 p ⊕ 2^k 恰好翻转第 k 位，一步定位伙伴。加减法需要判断方向，而且不满足“翻转即可得邻居”的对称性；AND 根本改不了位。

Q4. 以下哪些是内存池减少碎片的常用手段？

多选题 · mid

  • A.伙伴合并相邻空闲块← 正确答案
  • B.大小类分级管理← 正确答案
  • C.定期内存规整← 正确答案
  • D.增加系统调用频率

答案：ABC。伙伴合并把相邻同档空闲块拼成大块；大小类分级让同尺寸块共享链表，避免反复切分；内存规整搬运活跃对象腾出连续空间。增加系统调用只会加剧碎片和开销，与目标背道而驰。

Q5. 某程序通过内存池申请 100 字节对象，池将其归入 128B 档位，该对象造成的内部碎片为？

单选题 · mid

  • A.28 字节← 正确答案
  • B.100 字节
  • C.128 字节
  • D.0 字节

答案：A。内碎片 = 分配档位 − 请求大小 = 128 − 100 = 28 字节。如同肉末装进大盘子，盘内多出的空间就是内部碎片。100 和 128 分别是请求和分配值，0 则表示无浪费，均不符合。

Q6. 线程本地池取块耗时 10ns，概率 90%；全局池兜底耗时 100ns，概率 10%。平均分配耗时是多少？

单选题 · hard

  • A.55ns
  • B.19ns← 正确答案
  • C.10ns
  • D.100ns

答案：B。按加权平均公式 t̄ = 0.9 × 10 + 0.1 × 100 = 19ns。55ns 是取两者平均的常见错误；10ns 忽略全局兜底；100ns 则高估了全局路径占比。本地命中率越高，平均耗时越贴近本地值。

Q7. 关于 AI 编译器中的内存池，下列说法正确的是？

多选题 · mid

  • A.张量缓存池可避免频繁申请释放← 正确答案
  • B.图内存规划复用生命周期不重叠的张量← 正确答案
  • C.端侧推理不需要内存池
  • D.池化能有效降低峰值内存← 正确答案

答案：ABD。PyTorch 的 CachingAllocator 正是张量缓存池的典型；图内存规划把死亡早的张量内存让给新生张量，压低峰值；端侧内存紧张，更需要池来防抖动。C 与工程实践完全相反。

Q8. 下列哪一项描述的是“内部碎片”？

单选题 · easy

  • A.空闲块之间有零散空隙
  • B.分配档位大于请求大小造成浪费← 正确答案
  • C.内存池向系统申请了过多内存
  • D.缓存未命中导致的性能损失

答案：B。内部碎片是“分到的比要的多”导致的格子内浪费。A 是外部碎片，C 是池膨胀，D 属于缓存性能问题。好比买了个大包装，里面只装了一半东西。

Q9. 池膨胀率 E = 池总容量 / 实际使用量。当 E 远大于 1 时，合理的做法是？

单选题 · hard

  • A.继续扩大预分配以提升命中率
  • B.调小初始容量并支持池收缩← 正确答案
  • C.彻底改用系统默认分配器
  • D.增加并发线程数量

答案：B。E 过大说明大量内存闲置，应下调初始预分配，并增加动态收缩/归还机制。A 会雪上加霜；C 丢掉池化收益，矫枉过正；D 与内存占用无直接关联。

Q10. 下列哪些策略能缓解多线程内存池的锁竞争？

多选题 · hard

  • A.每线程维护私有 Free List← 正确答案
  • B.全局唯一大锁保护所有块
  • C.用无锁 CAS 操作管理空闲块← 正确答案
  • D.完全禁用内存池

答案：AC。线程私有 Free List 让大多数分配不触碰全局锁，是主流方案；CAS 无锁结构能进一步降低竞争代价。B 把所有线程压在同一把锁上，竞争更严重；D 是放弃治疗，而不是缓解。