Agent Skills › samber/cc-skills-golang › golang-concurrency

golang-concurrency

GitHub

Go并发编程技能，涵盖goroutine生命周期、channel/select用法、同步原语及worker pool模式。用于编写或审查并发代码，确保无泄漏和正确性，避免资源浪费。

skills/golang-concurrency/SKILL.md samber/cc-skills-golang

Trigger Scenarios

编写Go并发代码审查并发相关PR 选择Channel或Mutex 排查goroutine泄漏风险

Install

npx skills add samber/cc-skills-golang --skill golang-concurrency -g -y

More Options

Use without installing

npx skills use samber/cc-skills-golang@golang-concurrency

指定 Agent (Claude Code)

npx skills add samber/cc-skills-golang --skill golang-concurrency -a claude-code -g -y

安装 repo 全部 skill

npx skills add samber/cc-skills-golang --all -g -y

预览 repo 内 skill

npx skills add samber/cc-skills-golang --list

SKILL.md

Frontmatter

{
    "name": "golang-concurrency",
    "paths": [
        "**\/*.go"
    ],
    "license": "MIT",
    "metadata": {
        "author": "samber",
        "version": "1.2.1",
        "openclaw": {
            "emoji": "⚡",
            "install": [],
            "homepage": "https:\/\/github.com\/samber\/cc-skills-golang",
            "requires": {
                "bins": [
                    "go"
                ]
            }
        }
    },
    "description": "Golang concurrency design — goroutine lifecycle and leak prevention, channels and `select`, channel ownership and direction, `sync.Mutex`\/`RWMutex`\/`sync.Map`\/`sync.Once`\/atomics, `errgroup`, `singleflight`, worker pools, and fan-out\/fan-in pipelines. Use when writing or reviewing concurrent Go code, when choosing between channels and mutexes, when protecting a shared map or counter, or when a goroutine has no clear exit. Not for defensive coding unrelated to concurrency such as nil panics, slice aliasing, or numeric overflow (→ See `samber\/cc-skills-golang@golang-safety` skill), and not for debugging a specific hung, crashing, or racing program after the fact (→ See `samber\/cc-skills-golang@golang-troubleshooting` skill).",
    "allowed-tools": "Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion",
    "compatibility": "Designed for Claude Code, Codex or similar harness, and for projects using Golang.",
    "user-invocable": true
}

Persona: You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.

Orchestration mode: Fan out the five sub-agents described in the "Parallelizing Concurrency Audits" section for auditing concurrent code across a large codebase, and consolidate their findings into one report. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.

Modes:

Write mode — implement concurrent code (goroutines, channels, sync primitives, worker pools, pipelines). Follow the sequential instructions below.
Review mode — reviewing a PR's concurrent code changes. Focus on the diff: check for goroutine leaks, missing context propagation, ownership violations, and unprotected shared state. Sequential.
Audit mode — auditing existing concurrent code across a codebase. Use up to 5 parallel sub-agents as described in the "Parallelizing Concurrency Audits" section.

Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-concurrency skill takes precedence.

Go Concurrency Best Practices

Go's concurrency model is built on goroutines and channels. Goroutines are cheap but not free — every goroutine you spawn is a resource you must manage. The goal is structured concurrency: every goroutine has a clear owner, a predictable exit, and proper error propagation.

Core Principles

Every goroutine must have a clear exit — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes
Share memory by communicating — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit
Send copies, not pointers on channels — sending pointers creates invisible shared memory, defeating the purpose of channels
Only the sender closes a channel — closing from the receiver side panics if the sender writes after close
Specify channel direction (chan<-, <-chan) — the compiler prevents misuse at build time
Default to unbuffered channels — larger buffers mask backpressure; use them only with measured justification
Always include ctx.Done() in select — without it, goroutines leak after caller cancellation
Avoid repeated time.After in hot loops — each call allocates a timer and creates unnecessary churn; use time.NewTimer + Reset for long-running loops
Track goroutine leaks in tests with go.uber.org/goleak

For detailed channel/select code examples, see Channels and Select Patterns.

Channel vs Mutex vs Atomic

Scenario	Use	Why
Passing data between goroutines	Channel	Communicates ownership transfer
Coordinating goroutine lifecycle	Channel + context	Clean shutdown with select
Protecting shared struct fields	`sync.Mutex` / `sync.RWMutex`	Simple critical sections
Simple counters, flags	`sync/atomic`	Lock-free, lower overhead
Many readers, few writers on a map	`sync.Map`	Optimized for read-heavy workloads. Concurrent map read/write causes a hard crash
Caching expensive computations	`sync.Once` / `singleflight`	Execute once or deduplicate

WaitGroup vs errgroup

Need	Use	Why
Wait for goroutines, errors not needed	`sync.WaitGroup`	Fire-and-forget
Wait + collect first error	`errgroup.Group`	Error propagation
Wait + cancel siblings on first error	`errgroup.WithContext`	Context cancellation on error
Wait + limit concurrency	`errgroup.SetLimit(n)`	Built-in worker pool

Sync Primitives Quick Reference

Primitive	Use case	Key notes
`sync.Mutex`	Protect shared state	Keep critical sections short; never hold across I/O
`sync.RWMutex`	Many readers, few writers	Never upgrade RLock to Lock (deadlock)
`sync/atomic`	Simple counters, flags	Prefer typed atomics (Go 1.19+): `atomic.Int64`, `atomic.Bool`
`sync.Map`	Concurrent map, read-heavy	No explicit locking; use `RWMutex`+map when writes dominate
`sync.Pool`	Reuse temporary objects	Always `Reset()` before `Put()`; reduces GC pressure
`sync.Once`	One-time initialization	Go 1.21+: `OnceFunc`, `OnceValue`, `OnceValues`
`sync.WaitGroup`	Waiting for simple goroutines	Go 1.25+: prefer `wg.Go(func(){ ... })` for fire-and-wait tasks that do not panic and do not need error propagation. For Go <1.25 use `Add`/`Done`. For errors/cancellation/limits, use `errgroup` with context.
`x/sync/singleflight`	Deduplicate concurrent calls	Cache stampede prevention
`x/sync/errgroup`	Goroutine group + errors	`SetLimit(n)` replaces hand-rolled worker pools

For detailed examples and anti-patterns, see Sync Primitives Deep Dive.

Concurrency Checklist

Before spawning a goroutine, answer:

How will it exit? — context cancellation, channel close, or explicit signal
Can I signal it to stop? — pass context.Context or done channel
Can I wait for it? — sync.WaitGroup or errgroup
Who owns the channels? — creator/sender owns and closes
Should this be synchronous instead? — don't add concurrency without measured need

Pipelines and Worker Pools

For pipeline patterns (fan-out/fan-in, bounded workers, generator chains, Go 1.23+ iterators, samber/ro), see Pipelines and Worker Pools.

Parallelizing Concurrency Audits

When auditing concurrency across a large codebase, use up to 5 parallel sub-agents:

Find all goroutine spawns (go func, go method) and verify shutdown mechanisms
Search for mutable globals and shared state without synchronization
Audit channel usage — ownership, direction, closure, buffer sizes
Find time.After in loops, missing ctx.Done() in select, unbounded spawning
Check mutex usage, sync.Map, atomics, and thread-safety documentation

Common Mistakes

Mistake	Fix
Fire-and-forget goroutine	Provide stop mechanism (context, done channel)
Closing channel from receiver	Only the sender closes
`time.After` in hot loop	Reuse `time.NewTimer` + `Reset`
Missing `ctx.Done()` in select	Always select on context to allow cancellation
Unbounded goroutine spawning	Use `errgroup.SetLimit(n)` or semaphore
Sharing pointer via channel	Send copies or immutable values
`wg.Add` inside goroutine	Call `Add` before `go` — `Wait` may return early otherwise
Forgetting `-race` in CI	Always run `go test -race ./...`
Mutex held across I/O	Keep critical sections short

Cross-References

→ See samber/cc-skills-golang@golang-performance skill for false sharing, cache-line padding, sync.Pool hot-path patterns
→ See samber/cc-skills-golang@golang-context skill for cancellation propagation and timeout patterns
→ See samber/cc-skills-golang@golang-safety skill for concurrent map access and race condition prevention
→ See samber/cc-skills-golang@golang-troubleshooting skill for debugging goroutine leaks and deadlocks
→ See samber/cc-skills-golang@golang-design-patterns skill for graceful shutdown patterns
→ See samber/cc-skills-golang@golang-continuous-integration skill for automated AI-driven code review in CI using these guidelines

Goroutine leak profile

The goroutine leak profile (experimental behind GOEXPERIMENT=goroutineleakprofile in Go 1.26) is generally available in runtime/pprof since Go 1.27 — no build flag required. It is a useful production-oriented leak signal alongside the existing tools below.

curl http://localhost:6060/debug/pprof/goroutineleak?debug=2
go tool pprof http://localhost:6060/debug/pprof/goroutineleak

Keep existing tools:

tests: go.uber.org/goleak
runtime count: runtime.NumGoroutine()
stack dump: /debug/pprof/goroutine?debug=2
race checks: go test -race ./...

References

Version History

bac46b0 Current 2026-09-03 09:50
适配Go 1.27特性，修正encoding/json/v2默认行为、goleak GA状态等过时描述，修复与其他技能的漂移问题。
147c067 2026-08-28 11:52
版本从v1.x升级至v2.0.0；优化了多智能体编排指令，移除了对特定AI工具的硬编码引用以增强跨平台兼容性，并添加了文件路径触发范围配置。
709b181 2026-07-25 07:35

Metadata

Files: 0
Version: bac46b0
Hash: b56255b7
Indexed: 2026-07-25 07:35

golang-concurrency

golang-concurrency

Trigger Scenarios

Install

SKILL.md

Go Concurrency Best Practices

Core Principles

Channel vs Mutex vs Atomic

WaitGroup vs errgroup

Sync Primitives Quick Reference

Concurrency Checklist

Pipelines and Worker Pools

Parallelizing Concurrency Audits

Common Mistakes

Cross-References

Goroutine leak profile

References

Version History

Same Skill Collection

Metadata

文库