关闭 os.Root 后并发中的文件操作会发生什么

os.Root 可以被多个 goroutine 并发使用，但这不意味着可以在任意时刻调用 Close 而不考虑业务生命周期。结论是：已经进入 Root 方法的在途操作，在当前 Go 的 openat 实现中会通过引用计数保住底层目录句柄；Close 之后才开始的 Root 方法会返回错误，可用 errors.Is(err, os.ErrClosed) 识别；已经成功打开并返回的 *os.File 则有自己的句柄与关闭责任。

Root.Close 是资源状态切换，不是“等待所有业务任务完成”的停机屏障。想要确定性的关闭结果，应由上层资源所有者先停止准入，再等待在途任务归零，最后关闭 Root。

官方文档：https://pkg.go.dev/os#Root

规模背景：一个 Root 被整个工作池共享

文件索引、静态资源服务、归档解包和构建缓存常会创建一个 *os.Root，再把它交给多个 worker 并发调用。这样既能把访问限制在目录树内，也能避免每个请求重复打开根目录。官方文档明确说明 Root 的方法可以被多个 goroutine 同时使用，因此“多个读取并行”本身没有问题。

真正容易出错的是资源所有权。若某个请求 goroutine、热重载回调或超时清理任务直接调用 root.Close()，同一时刻可能仍有其他 worker 正在 ReadFile、Stat 或 Open。这时不能只用“并发安全”四个字推断所有调用都会成功，也不能把 Close 返回当作整个工作池已经停止。

Close 与并发操作真正相遇时会发生什么

公开 API 给出的稳定契约很简洁：调用 Close 后，Root 上的方法返回错误；Name 是少数明确允许在关闭后调用的方法。进一步查看当前 Go 源码中的 root_openat.go，可以看到 Root 内部维护了互斥锁、refs 和 closed：

• Root 方法进入路径解析前先执行 incref。若此时已经 closed，立即返回 os.ErrClosed。
• 已经成功 incref 的操作会增加 refs，并在结束时执行 decref。
• Close 把 closed 设为 true。若 refs 仍大于零，它不会立刻关闭底层目录句柄；最后一个在途操作 decref 时才真正释放句柄。
• Close 本身不会等待 refs 归零，因此它可以先返回，而业务操作仍在收尾。

因此，同一时刻与 Close 竞争的调用存在两类结果：先取得引用的调用按原操作继续执行；后取得锁并看到 closed 的调用返回关闭错误。调度顺序决定它落在哪一类，业务代码不应假设“发起时间更早”就必然先取得引用。

还要区分 Root 与它打开的文件。官方 OpenInRoot 的实现会创建临时 Root，defer r.Close() 后返回 r.Open(name) 得到的 *os.File。这说明已经成功返回的 File 拥有独立生命周期，之后应由调用者关闭；Root.Close 限制的是继续通过该 Root 发起路径操作。

原架构瓶颈：把 Close 当成广播取消

一种常见设计是主 goroutine 收到退出信号后直接 Close，期望所有 worker 自动停止。它有三个问题：第一，Close 不会替你阻止队列继续投递；第二，在途调用可能仍在执行，Close 返回不能作为“磁盘操作全部结束”的证明；第三，worker 得到的 os.ErrClosed 容易与真实的文件不存在、权限错误混在一起，产生误报警。

更危险的写法是让多个组件各自 defer root.Close()。谁先结束，谁就会让其他组件的后续调用失败。Root 应当只有一个生命周期所有者，worker 只能借用，不能决定关闭时机。

新架构：先关准入，再排空，最后关闭 Root

下面的包装器把“是否还接收新任务”和“有多少任务正在使用 Root”纳入同一把锁。这样可避免 WaitGroup.Add 与 Wait 并发造成的不确定性。第一个 Close 调用者关闭准入并负责排空；后续 Close 调用者等待同一个完成信号。

package rootstore

import (
    "errors"
    "os"
    "sync"
)

var ErrStoreClosing = errors.New("root store is closing")

type Store struct {
    root *os.Root

    mu       sync.Mutex
    closing  bool
    inFlight sync.WaitGroup
    done     chan struct{}
    closeErr error
}

func Open(dir string) (*Store, error) {
    root, err := os.OpenRoot(dir) // 根目录只由 Store 创建和持有
    if err != nil {
        return nil, err
    }
    return &Store{root: root, done: make(chan struct{})}, nil
}

func (s *Store) begin() error {
    s.mu.Lock()
    defer s.mu.Unlock()
    if s.closing { // 关闭准入后不再增加在途计数
        return ErrStoreClosing
    }
    s.inFlight.Add(1) // Add 与 closing 检查处于同一临界区
    return nil
}

func (s *Store) ReadFile(name string) ([]byte, error) {
    if err := s.begin(); err != nil {
        return nil, err
    }
    defer s.inFlight.Done() // 无论成功还是失败都释放在途名额
    return s.root.ReadFile(name)
}

func (s *Store) Close() error {
    s.mu.Lock()
    if s.closing { // 多个关闭者复用同一个完成信号
        done := s.done
        s.mu.Unlock()
        

这个结构没有依赖 Root 当前实现“让在途引用继续”的细节，而是在业务层主动建立更强的语义：Close 返回时，所有通过 Store 发起的操作都已经结束，且不会再有新操作进入。若请求还需要支持超时，可以在准入层接受 context.Context，但不要用关闭 Root 代替请求取消。

关键取舍：立即拒绝还是等待完成

如果系统需要热切换 Root，不要原地替换共享指针后立刻关闭旧值。更稳妥的做法是为每一代 Root 建立独立 owner：新请求只进入新一代，旧一代停止准入并等待自己的 in-flight 归零，然后再 Close。这样能把切换期间的错误从随机竞态变成可观测状态。

上线后的运行信号与测试

至少记录四个指标：当前在途文件操作数、进入 closing 后被拒绝的请求数、排空耗时、按 errors.Is(err, os.ErrClosed) 分类的关闭错误数。正常优雅停机中，Store 层应优先返回可识别的 ErrStoreClosing；若仍大量看到 os.ErrClosed，通常意味着存在绕过 owner 直接使用 Root 的路径。

并发测试不要断言某个与 Close 同时启动的 goroutine 必然成功或失败，因为调度次序没有确定性。应测试稳定不变量：关闭准入后不会新增 in-flight；Close 在已进入操作结束前不返回；Close 完成后所有新请求都被拒绝；已经获得的 *os.File 由调用者独立关闭。再配合 go test -race 检查包装器自身的数据竞争。

相关问题

Root 的并发安全是否等于 Close 可以随便调用？ 不是。并发安全保证内部状态不会因并发调用而被破坏，不保证所有业务调用都成功，也不替上层定义谁拥有关闭权。

Close 后的错误一定能用 os.ErrClosed 判断吗？ 官方源码在关闭状态的入口返回 os.ErrClosed，调用方应使用 errors.Is，不要比较错误字符串。业务包装层还可以先返回自己的 closing 错误，把正常停机与资源误用分开。

为什么还要 WaitGroup，Root 内部不是已经有 refs 吗？ refs 保护的是底层句柄不会被在途操作提前释放；它不是公开的等待接口，而且 Close 不等待 refs 归零。WaitGroup 解决的是业务层“Close 返回时全部任务已经完成”的更强契约。