单函数单次调用限制下，如何组织Goroutines并行处理多输入的通信？

Hey there! Great question—this is a super common scenario in Go when dealing with functions that can’t safely handle concurrent calls. Let’s break down the cleanest ways to coordinate your goroutines, leaning into Go’s core concurrency principles first, then covering a more straightforward alternative.

Channel-Based Token Coordination (The Go Idiomatic Way) #

Go’s mantra is "Don’t communicate by sharing memory; share memory by communicating", so using a channel as a "token" is the most idiomatic approach here. The idea is simple: only the goroutine that holds the token can call your restricted function. Once it’s done, it passes the token back so another goroutine can use it.

How it works: #

• Create an unbuffered channel (or a buffered one if you ever need to allow N concurrent calls later)
• Initialize the channel with a single "token" (we use struct{}{} since it’s memory-efficient)
• Each goroutine waits to receive the token before executing the restricted function, then sends it back once done

Example Code: #

package main

import (
    "fmt"
    "sync"
    "time"
)

// 这个函数同一时间只能被一个goroutine调用
func restrictedFunc() {
    fmt.Println("🔧 Executing restricted function...")
    time.Sleep(1 * time.Second) // 模拟耗时操作
}

func main() {
    // 创建无缓冲channel作为令牌容器，先放入一个令牌
    token := make(chan struct{})
    token <- struct{}{}

    var wg sync.WaitGroup
    const numGoroutines = 10

    for i := 0; i < numGoroutines; i++ {
        wg.Add(1)
        go func(goroutineID int) {
            defer wg.Done()
            fmt.Printf("Goroutine %d: Waiting for access to restricted function\n", goroutineID)
            
            // 等待获取令牌
            <-token
            // 确保调用完成后放回令牌，即使函数出错也不会丢失令牌
            defer func() { token <- struct{}{} }()

            restrictedFunc()
            fmt.Printf("Goroutine %d: Finished executing restricted function\n", goroutineID)
        }(i)
    }

    // 等待所有goroutine完成
    wg.Wait()
    close(token) // 可选：不再需要令牌时关闭channel
}

Why this works: #

An unbuffered channel only allows one sender and one receiver at a time. This guarantees that only one goroutine holds the token (and thus can call restrictedFunc) at any moment. If you later need to allow 2 concurrent calls, just switch to a buffered channel with make(chan struct{}, 2)—super flexible!

Alternative: Using a Mutex #

If you prefer a more direct approach (or if modifying the restricted function is an option), a sync.Mutex works perfectly. It acts as a lock that only one goroutine can hold at a time, ensuring exclusive access to the function.

Example Code: #

package main

import (
    "fmt"
    "sync"
    "time"
)

var accessLock sync.Mutex

func restrictedFunc() {
    // 在函数内部加锁，确保调用它的goroutines自动排队
    accessLock.Lock()
    defer accessLock.Unlock()

    fmt.Println("🔧 Executing restricted function...")
    time.Sleep(1 * time.Second)
}

func main() {
    var wg sync.WaitGroup
    const numGoroutines = 10

    for i := 0; i < numGoroutines; i++ {
        wg.Add(1)
        go func(goroutineID int) {
            defer wg.Done()
            fmt.Printf("Goroutine %d: Waiting for access to restricted function\n", goroutineID)
            
            restrictedFunc()
            fmt.Printf("Goroutine %d: Finished executing restricted function\n", goroutineID)
        }(i)
    }

    wg.Wait()
}

When to use this: #

This is great for simple cases where you don’t need the flexibility of channels. If the restricted function is a third-party one you can’t modify, just move the lock around the function call in your goroutine:

go func(goroutineID int) {
    defer wg.Done()
    fmt.Printf("Goroutine %d: Waiting for access\n", goroutineID)
    
    accessLock.Lock()
    restrictedFunc() // 第三方函数，无法修改内部逻辑
    accessLock.Unlock()
    
    fmt.Printf("Goroutine %d: Done\n", goroutineID)
}(i)

Final Notes #

• Prefer channels if you want to stick to Go’s concurrency idioms, need flexibility (like adjusting concurrent limits later), or want to build more complex coordination patterns (e.g., timeouts on waiting for access)
• Use mutexes for simple, straightforward exclusive access scenarios where you don’t need the extra features channels provide

内容的提问来源于stack exchange，提问作者Ivan Vodopyanov