WeakRef实现WebGL纹理缓存优化

WeakRef 无法自动管理 WebGL 纹理的生命周期，它仅能弱引用 JS 层轻量 wrapper 对象（如 `{ texture, id }`），而无法安全持有或感知底层 GPU 纹理句柄的真实状态；真正释放显存必须由业务主动调用 `gl.deleteTexture()`，WeakRef 仅辅助探测 JS 引用是否存活，误将其当作自动回收机制将导致纹理泄漏、显存暴涨或静默失效——因此，稳健的纹理缓存必须采用“WeakRef 探测 + 显式 delete() 驱动”的混合模式，并确保 wrapper 被长期强引用（如挂载在全局缓存实例或 React state/ref 中），否则缓存链路会因 wrapper 被 GC 而瞬间断裂。

WeakRef 本身不能触发 WebGL 资源释放，它只提供“可被 GC 的弱引用”，真正释放必须调用 gl.deleteTexture()；缓存有效性取决于你是否在业务中维持强引用，否则 WeakRef 持有的 texture 会立刻失效。

为什么 WeakRef 不能直接管理 WebGL 纹理生命周期

WebGLTexture 实例不是 JS 可控的普通对象：它背后是 GPU 句柄，JS 引擎无法通过弱引用感知其真实存活状态。WeakRef 只能追踪 JS 层 wrapper 对象（如 { texture, id }），而不能安全包裹 gl.createTexture() 返回的原始 texture 对象——后者在某些浏览器中甚至无法被 WeakRef 正确持有。

常见错误现象：weakRef.deref() 突然返回 undefined，但纹理仍在 GPU 中占用内存；或更糟：业务逻辑误以为资源已释放，重复创建新纹理导致显存翻倍。

• WeakRef 不等于自动释放，它只是“不阻止 GC”的引用方式
• texture 对象本身不可被 WeakRef 安全持有（Chrome 120+ 有部分支持，但 Safari 和旧版 Firefox 会静默失败）
• 必须用一个轻量 wrapper 对象（如 { texture, createdAt }）作为 WeakRef 的目标，再由 wrapper 关联真实 texture

如何构造一个真正可用的 WeakRef + 显式释放混合管理器

核心思路：WeakRef 仅用于“探测是否还有活跃引用”，所有释放动作仍由明确的业务节点（如组件卸载、场景切换）驱动，WeakRef 回调只作日志或告警。

示例结构：

class TextureCache {
  constructor(gl) {
    this.gl = gl;
    this.cache = new Map(); // key: id → { ref: WeakRef, createdAt: Date }
  }

  get(id) {
    const entry = this.cache.get(id);
    if (!entry) return null;
    const texture = entry.ref.deref();
    return texture ?? null; // 可能已 GC，但 GPU 内存未清
  }

  set(id, texture) {
    // 必须包装，不能直接 new WeakRef(texture)
    const wrapper = { texture, id, gl: this.gl };
    this.cache.set(id, {
      ref: new WeakRef(wrapper),
      createdAt: Date.now()
    });
  }

  // ✅ 真正释放入口：业务调用此方法
  delete(id) {
    const entry = this.cache.get(id);
    if (entry && entry.ref.deref()) {
      this.gl.deleteTexture(entry.ref.deref().texture);
    }
    this.cache.delete(id);
  }
}

• WeakRef 持有的是 wrapper，不是 texture；wrapper 中保留 gl 引用是为了在 delete() 时能调用正确上下文
• get() 返回 null 并不表示 texture 已释放，只表示 JS 层无强引用——GPU 内存可能还在
• 必须暴露 delete() 方法供业务主动调用，不能依赖 WeakRef 回调清理

WeakRef 回调里能做什么（以及绝对不能做什么）

WeakRef 不支持注册回调（那是 FinalizationRegistry 的事），所以想“自动触发释放”必须组合使用：WeakRef + FinalizationRegistry。但要注意两者分工：

• FinalizationRegistry 注册时，键必须是 wrapper 对象（同上），不能是 texture
• 回调中禁止任何 this.gl.deleteTexture() 调用——此时 this.gl 很可能已丢失或无效
• 回调中只允许：记录 console.warn(`Texture ${id} leaked, never deleted`)、上报监控埋点、触发开发者工具提示
• 如果真要尝试兜底清理，先检查 this.gl.isContextLost?.() === false，但不要依赖它成功

按需缓存的实际生效条件是什么

“按需缓存”效果是否成立，完全取决于你的业务是否维持了对 wrapper 的强引用。一旦 wrapper 被 GC，WeakRef 就失效，缓存即断链——这不是 bug，是 WeakRef 的设计本意。

典型失效场景：

• 在函数作用域内创建 wrapper 并传给 WeakRef，函数退出后 wrapper 立刻被回收
• React 组件中每次渲染都新建 wrapper，但没保存到 state 或 ref 中，导致缓存无法跨渲染周期存在
• 把 wrapper 存在局部变量或未导出的模块变量里，模块被热更新或重载后引用丢失

真正稳定的缓存，需要 wrapper 至少被一个长期存活的对象持有（如全局 TextureCache 实例、React Context 提供的 store、或 class 实例的属性）。WeakRef 只是让这个持有关系“不阻碍 GC”，而不是“替代持有”。

今天关于《WeakRef实现WebGL纹理缓存优化》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！