Go x/sync/semaphore.Weighted.TryAcquire 怎样非阻塞获取并发令牌

在入口请求不能长时间等待时，semaphore.Weighted.TryAcquire 很适合做一次“现在有没有足够资源”的非阻塞判断：成功返回 true 并占用请求的权重，失败返回 false，调用方立即决定拒绝、排队或换成可取消的等待。它不会返回等待错误，也不会在失败时悄悄扣掉令牌。

官方文档：https://pkg.go.dev/golang.org/x/sync/semaphore#Weighted.TryAcquire

把 TryAcquire 当作业务入口的容量检查，而不是任务队列。只有拿到令牌后才启动工作，并用同一个权重调用 Release。

先把 TryAcquire 当成一次非阻塞资源检查

Weighted 用一个总权重表示并发资源上限。创建时的容量是可同时持有的最大权重，调用方通过 TryAcquire(n) 申请非负的 n。如果当前可用权重足够，返回值为 true；否则立刻返回 false，信号量保持原状。

下面的写法把“获取成功”与“启动任务”放在同一个判断里。没有拿到令牌时直接返回业务错误，调用方不会被信号量阻塞。

package limiter

import (
    "errors"
    "golang.org/x/sync/semaphore"
)

var ErrBusy = errors.New("resource is busy")

func Submit(sem *semaphore.Weighted, weight int64, work func()) error {
    // TryAcquire 只做即时检查，失败时不等待也不改变信号量。
    if !sem.TryAcquire(weight) {
        return ErrBusy
    }

    go func() {
        // 只有成功获取后才启动任务，并归还完全相同的权重。
        defer sem.Release(weight)
        work()
    }()
    return nil
}

这里最容易漏掉的是 Release(weight)。它不是“释放一个任务”，而是释放本次申请的权重；申请 3 却只释放 1，会让容量逐渐被吞掉。

权重不是并发数，申请和归还必须配对

权重适合表达不同任务的资源成本，例如普通任务占 1 个单位，导出任务占 4 个单位。容量为 8 时，已经占用 6 个单位，新的 3 单位申请就会失败，即使当前 goroutine 数量看起来还不多。

TryAcquire 与 Acquire 的区别只在等待方式：Acquire 会等资源可用或上下文结束，成功返回 nil；TryAcquire 直接返回布尔值。两者都要求调用方在成功后按原权重归还。

func startExport(sem *semaphore.Weighted, export func()) bool {
    const exportWeight int64 = 4

    // 权重体现导出任务的资源成本，不应拿 goroutine 数量代替它。
    if !sem.TryAcquire(exportWeight) {
        return false
    }

    go func() {
        // defer 覆盖正常返回和 panic 前的清理路径。
        defer sem.Release(exportWeight)
        export()
    }()
    return true
}

不要在信号量已经被持有时修改它的内部容量，也不要把一个大于总容量的权重当成普通失败处理后无限重试；这种请求应在业务层提前拆分、降级或明确拒绝。

拿不到令牌时怎样选择回退策略

失败不是异常，而是一个清晰的容量信号。HTTP 快速入口通常直接返回稍后重试；后台任务可以把任务写入已有队列；如果业务必须等待，则改用 Acquire(ctx, n)，让等待受截止时间和取消信号控制。不要把 TryAcquire 放进无间隔的死循环，否则只是把阻塞从信号量内部搬到了 CPU。

func submitWithFallback(
    sem *semaphore.Weighted,
    ctx context.Context,
    work func(),
) error {
    const weight int64 = 2

    // 快速路径不等待，适合不允许拖慢请求入口的场景。
    if sem.TryAcquire(weight) {
        go func() {
            // 工作结束必须归还令牌，避免后续请求永久降级。
            defer sem.Release(weight)
            work()
        }()
        return nil
    }

    // 需要等待时使用带上下文的 Acquire，让取消和超时可控。
    if err := sem.Acquire(ctx, weight); err != nil {
        return err
    }
    go func() {
        // Acquire 成功后同样按原权重归还资源。
        defer sem.Release(weight)
        work()
    }()
    return nil
}

示例中的两条路径都可以启动工作，但生产代码应先明确业务语义：入口请求是否能排队、队列是否有长度上限、上下文取消后是否还允许开始任务。信号量只负责资源占用，不替你回答这些策略问题。

三个容易让非阻塞限额失效的细节

• 成功后才启动 goroutine：先启动、再尝试获取会让未受控的工作已经开始。
• 权重必须对称：每次成功的 TryAcquire(n) 或 Acquire(ctx, n) 都要对应一次 Release(n)。
• 失败要有结果：返回忙、进入有界队列或等待上下文，不能靠紧密轮询制造隐性排队。

如果只是限制同时运行的任务数，可以统一让每个任务申请权重 1；如果任务成本不同，再使用权重。这样读代码的人能直接看出容量单位，也更容易检查释放是否完整。

相关问题

TryAcquire 失败后需要调用 Release 吗？

不需要。失败返回 false 时信号量没有改变，只有成功获取后才需要归还对应权重。

TryAcquire 能像 Acquire 一样响应 context 吗？

它本身不接收 context，也不会等待。需要可取消等待时使用 Acquire(ctx, n)，并处理返回的上下文错误。

信号量满了应该自动把任务放到哪里？

不会自动排队。由业务决定立即拒绝、写入有界队列或在调用方使用带截止时间的 Acquire。

记住一句话：TryAcquire 负责“现在能不能拿到”，回退策略负责“拿不到时怎么办”，而 Release 负责让资源生命周期闭合。