避免显存溢出：WebGPU 中 GPUBuffer 内存释放的特殊要求及其与 GPUTexture 的异同

在 WebGL 时代，许多开发者习惯了依赖 JavaScript 的垃圾回收（GC）机制来顺便释放底层的 GPU 资源。然而，在 WebGPU 这套现代图形 API 中，显存管理走向了“半手动时代”。

如果编写复杂的 WebGPU 应用（如大模型端侧推理、大型 WebGIS、高精度的 3D 渲染器）却依然沿用 WebGL 的“甩手掌柜”式写法，很容易在短时间内因显存占用过高而导致浏览器标签页崩溃（OOM）。

本文将深入探讨 WebGPU 中 GPUBuffer 的内存释放特殊要求，并详细对比它与 GPUTexture 在生命周期管理上的异同。

一、 GPUBuffer 内存释放的特殊要求

GPUBuffer 是 WebGPU 中用于存储线性、无格式字节数据的最基础资源。它的释放并不只是简单地调用一个销毁方法，其背后涉及到 CPU 与 GPU 之间的异步协同、内存映射状态等复杂机制。

1. 显式销毁与隐式垃圾回收的“时间差”

虽然垃圾回收器（GC）最终会回收 JS 端的 GPUBuffer 对象，但JS 堆内存的回收与 GPU 显存（VRAM）的释放是完全不同步的。

• 当你将 buffer 变量设为 null 时，JS 引擎可能认为当前内存压力不大而延迟 GC。
• 在这期间，底层的显存依然被该 Buffer 占用。
• 特殊要求：在确定 Buffer 不再使用时，必须手动调用 buffer.destroy()。这会立即向 WebGPU 后端（如 Vulkan、Metal、Direct3D 12）发出释放底层显存的指令，而无需等待 GC。

2. GPU 延迟释放（Deferred Destruction）

调用 buffer.destroy() 后，该 Buffer 立即在 JS 端进入“已销毁”状态，任何后续将其绑定到 BindGroup 或提交到 CommandEncoder 的操作都会抛出 Validation Error。

但是，如果 GPU 当前正在执行的队列（Queue）中仍有 CommandBuffer 引用了该 Buffer，底层的显存并不会被立刻回收。WebGPU 内部会维护一个引用计数，直到 GPU 彻底完成相关渲染或计算任务后，显存才会被真正释放。这一机制保证了显式销毁操作不会导致 GPU 崩溃。

3. 映射（Mapped）状态的强制解除

这是 GPUBuffer 独有的核心特征。为了让 CPU 读写 GPUBuffer，我们通常会使用 mapAsync() 或在创建时设置 mappedAtCreation: true。

当一个 Buffer 处于 Mapped 状态时，它在 JS 端会暴露一个 ArrayBuffer（通过 getMappedRange() 获取）。

• 特殊要求：如果你在 Buffer 仍处于 Mapped 状态时调用 destroy()，WebGPU 会隐式地、强制性地调用 unmap()。
• 这会导致之前通过 getMappedRange() 获取的 JS ArrayBuffer 瞬间被 Detached（分离）。任何后续对该 ArrayBuffer 的读写操作都会抛出 TypeError: Cannot perform %TypedArray%.prototype.set on a detached ArrayBuffer。

const buffer = device.createBuffer({
    size: 1024,
    usage: GPUBufferUsage.COPY_SRC | GPUBufferUsage.MAP_WRITE,
    mappedAtCreation: true
});

const arrayBuffer = buffer.getMappedRange();
const writeData = new Float32Array(arrayBuffer);
writeData[0] = 1.0;

// 显式销毁
buffer.destroy(); 

// 此时 arrayBuffer 已经被分离，长度变为 0
console.log(arrayBuffer.byteLength); // 0
// writeData[0] = 2.0; // 报错：TypeError

4. 销毁的不可逆性

一旦调用 destroy()，该 GPUBuffer 对象将无法通过任何手段恢复。如果需要再次使用相同大小和用途的 Buffer，必须重新调用 device.createBuffer()。

二、 GPUBuffer 与 GPUTexture 的异同

GPUBuffer 和 GPUTexture 都是 WebGPU 里的基础资源（继承自 GPUObjectBase），但由于它们在 GPU 硬件层面的存储布局和使用场景截然不同，其内存管理表现也存在明显的差异。

1. 核心异同对比表

2. 深入理解：TextureView 的联动失效

在 WebGPU 中，我们不能直接将 GPUTexture 绑定到着色器（Shader）中，必须通过 GPUTextureView（通过 texture.createView() 创建）进行过渡。

• 当你调用 texture.destroy() 时，所有基于该 Texture 创建的 GPUTextureView 都会在瞬间失效。
• 如果尝试在之后的渲染通道（RenderPass）中使用这些失效的 View，WebGPU 会直接报错。
• 相比之下，GPUBuffer 没有 View 的概念（虽然有 GPUBufferBinding，但它只是一个描述符），销毁 Buffer 会直接导致包含它的 BindGroup 在执行时报错。

3. 深入理解：数据传输对内存释放的影响

因为 Texture 无法被 CPU 直接 Map，所以当我们想释放一个临时用于上传纹理数据的资源时，两者的链路是不同的：

• Buffer 链路：
  Create Mapped Buffer -> Write Data -> Unmap -> Copy Buffer to Destination -> Destroy Buffer。
  在这个链路中，Buffer 很快就会被 destroy，显存生命周期极短。

• Texture 链路：
  通常需要一个中间 Buffer（Staging Buffer）。
  Create Mapped Buffer -> Write Data -> Unmap -> Copy Buffer to Texture -> 同时销毁 Buffer -> 留下 Texture 长期驻留显存。
  此时，我们需要分别管理 Staging Buffer 的即时销毁，以及 Texture 在后续不再使用时的手动销毁。

三、 最佳实践：如何优雅地管理 WebGPU 内存？

为了防止显存泄漏，在实际工程中推荐采用以下模式来管理 GPUBuffer 和 GPUTexture 的释放。

1. 使用生命周期包装器（RAII 模式）

在复杂的应用中，可以实现一个简单的资源追踪器，将资源的创建和销毁闭环管理：

class ResourceManager {
    private activeBuffers = new Set<GPUBuffer>();
    private activeTextures = new Set<GPUTexture>();

    constructor(private device: GPUDevice) {}

    createBuffer(descriptor: GPUBufferDescriptor): GPUBuffer {
        const buffer = this.device.createBuffer(descriptor);
        this.activeBuffers.add(buffer);
        return buffer;
    }

    createTexture(descriptor: GPUTextureDescriptor): GPUTexture {
        const texture = this.device.createTexture(descriptor);
        this.activeTextures.add(texture);
        return texture;
    }

    destroyBuffer(buffer: GPUBuffer) {
        if (this.activeBuffers.has(buffer)) {
            buffer.destroy();
            this.activeBuffers.delete(buffer);
        }
    }

    destroyTexture(texture: GPUTexture) {
        if (this.activeTextures.has(texture)) {
            texture.destroy();
            this.activeTextures.delete(texture);
        }
    }

    // 切换场景或卸载组件时一键清空，防止内存泄漏
    destroyAll() {
        for (const buffer of this.activeBuffers) {
            buffer.destroy();
        }
        this.activeBuffers.clear();

        for (const texture of this.activeTextures) {
            texture.destroy();
        }
        this.activeTextures.clear();
    }
}

2. 临时 Buffer “用完即弃”

在向 GPU 传输一次性数据（如逐帧更新的 Uniform 数据，且没有使用 queue.writeBuffer 而是使用了暂存区）时，务必在 Copy 操作对应的 CommandBuffer 提交后，立刻执行 destroy()。

更好的做法是：对于频繁变动的小数据，优先使用 device.queue.writeBuffer() 或 device.queue.writeTexture()，它们由浏览器内部高度优化地管理暂存内存，能有效避免开发者频繁手动创建和销毁 Buffer 带来的 CPU 开销与内存碎片。

3. 利用 onSubmittedWorkDone() 确认安全销毁

如果你有一些体积巨大、需要安全释放并确认显存已归还给操作系统的资源，可以使用 device.queue.onSubmittedWorkDone()：

// 提交了使用该超大 Buffer 的渲染任务
device.queue.submit([commandBuffer]);

// 显式销毁（此时底层释放已排队）
largeBuffer.destroy();

// 等待 GPU 彻底完成所有工作，确保显存已安全释放
device.queue.onSubmittedWorkDone().then(() => {
    console.log("GPU 已处理完相关任务，底层显存已彻底回收");
});

总结

WebGPU 赋予了 Web 开发者前所未有的底层控制力，但这同时也伴随着管好显存的责任。

• GPUBuffer 释放时需额外注意 Map 状态的失效 以及 JS ArrayBuffer 的 Detach 现象。
• GPUTexture 释放时需注意其派生的 GPUTextureView 会同步失效。
• 牢记 destroy() 是释放显存的唯一即时手段，切勿将现代图形 API 的资源完全托付给 JS 垃圾回收器。