Python memoryview 使用后如何释放底层资源

memoryview 用完后，最明确的做法是调用 view.release()；如果使用边界清楚，直接写成 with memoryview(source) as view: 更稳妥。它释放的是视图持有的底层缓冲区导出，不是把 source 这个 Python 对象删除。视图释放后继续访问会抛出 ValueError，但可以重复调用 release()。

先分清 memoryview 和底层资源是谁

memoryview 是对支持缓冲区协议对象的一层视图，常见来源包括 bytearray、bytes 和内存映射。视图存在期间，导出者需要保证这段缓冲区仍然有效；因此可变对象可能暂时拒绝改变长度。这个限制保护的是视图仍在使用的地址，不代表 Python 对象本身发生了泄漏。

Python 官方文档把 release() 定义为释放视图暴露的底层缓冲区。调用后，视图不再可读写，任何普通操作都会得到“已释放 memoryview”的 ValueError。如果只是把变量名改成 None，其他别名或派生视图仍可能继续持有这份导出，释放时机就不够直观。

使用范围固定时优先用 with 自动释放

当数据只在一个函数或一个代码块内读取，with 能把释放边界写在结构里。离开代码块时，即使处理过程中抛出异常，视图也会执行释放。若要把视图中的一段数据交给外部，先复制成 bytes；否则把已经释放的视图返回出去，调用方拿到的只是一个不可用句柄。

def read_header(source: bytearray, size: int = 8) -> bytes:
    # 视图只在读取期间存在，返回 bytes 后不再依赖底层缓冲区。
    with memoryview(source) as view:
        if size  len(view):
            # 用明确的参数错误阻止越界读取。
            raise ValueError("size 超出缓冲区范围")
        return bytes(view[:size])


buffer = bytearray(b"PYTHON-buffer")
header = read_header(buffer, 6)
# 函数返回后，buffer 已经可以继续调整长度。
buffer.extend(b"-ok")
print(header, buffer)

如果需要手动控制生命周期，也要把 release() 放在 finally 中。这样写适合视图的使用范围跨过多个分支，但仍然由当前函数拥有它的情况。

view = memoryview(buffer)
try:
    # 这里执行需要零拷贝访问的解析逻辑。
    checksum = sum(view)
finally:
    # 无论解析成功还是失败，都解除缓冲区导出。
    view.release()

buffer.extend(b"-released")

为什么 bytearray 仍然不能扩容

最容易观察到的现象是：创建 memoryview(bytearray) 后，对原来的 bytearray 调用 extend() 可能得到 BufferError。原因不是 memoryview 把数据复制走了，而是可变长度操作可能改变底层地址，导出者必须等所有视图释放后才能调整容量。

buffer = bytearray(b"abc")
view = memoryview(buffer)
try:
    # 视图仍在使用，调整 bytearray 长度可能破坏它的地址稳定性。
    buffer.extend(b"d")
except BufferError:
    print("先释放 memoryview，再改变长度")
finally:
    # release 是幂等的，收尾时重复调用也不会再次占用资源。
    view.release()

buffer.extend(b"d")
print(buffer)

切片和 cast 产生的视图也要纳入清理

view[:4] 和 view.cast(...) 返回的仍是视图，不是自动复制出的独立字节串。工程代码中如果把它们保存到列表、缓存或异步任务里，原始视图变量释放后，派生视图仍可能延长缓冲区导出的生命周期。要么在边界处立刻转成 bytes，要么让每个拥有派生视图的对象负责结束它。

raw = bytearray(b"0123456789")
with memoryview(raw) as whole:
    # bytes 会复制当前片段，后续不再依赖 whole 或 sliced。
    copied = bytes(whole[2:6])
    with whole.cast("B") as byte_view:
        # 这里只使用派生视图完成一次按字节检查。
        has_digit = all(48 

不要把释放后的视图放进返回值或跨线程队列；如果消费者确实需要延迟读取，就把资源所有权一起传递，并在消费者的 finally 中释放。与其依赖引用计数或垃圾回收“稍后处理”，不如让所有权和结束点出现在接口约定中。

mmap 等场景要分两次收尾

如果视图来自 mmap.mmap，需要同时管理两个对象：先结束仍在使用的 memoryview，再关闭映射对象。release() 不会替你关闭文件描述符或映射；它只是让视图不再持有缓冲区。把两层上下文嵌套起来，通常比手动记顺序更不容易漏清理。

import mmap

with open("sample.bin", "rb") as file_obj:
    with mmap.mmap(file_obj.fileno(), 0, access=mmap.ACCESS_READ) as mapped:
        # memoryview 的退出必须发生在 mmap 关闭之前。
        with memoryview(mapped) as view:
            prefix = bytes(view[:16])

print(prefix)

排查资源迟迟不能关闭时，可以按“是否还有视图别名、是否保存了切片或 cast 结果、是否只丢了变量名、底层对象是否另有 close 方法”逐项检查。若异常发生在视图构造之后，清理代码仍应位于同一所有权边界内。

一张表判断该用哪种释放方式

常见问题

del view 能不能代替 release？

不建议把它当作明确的资源协议。del 只删除当前名称，其他引用仍可能存在；显式 release() 或 with 更能表达结束点。

release 后还能读取 view 吗？

不能。释放后的普通访问会抛 ValueError；需要保留数据时，应在释放前复制成 bytes 或其他独立对象。

调用 release 会关闭 mmap 吗？

不会。它只结束 memoryview 对缓冲区的持有；mmap、文件和其他底层资源仍需调用各自的关闭逻辑。

判断 Python memoryview 是否需要释放，关键不在于“对象大不大”，而在于它是否仍然持有缓冲区导出，以及后续是否要调整或关闭底层对象。把 with 用在短生命周期场景，把 try/finally 用在明确的所有权边界，再把派生视图和底层资源分别纳入清理，就能避免大多数 BufferError 和关闭顺序问题。