使用go关键字创建协程，它启动轻量级执行单元，由Go运行时在用户态调度，通过通道或sync包实现协程间通信与同步，需注意协程泄漏、竞态条件、循环变量捕获等问题。
在Go语言中，创建协程（goroutine）的核心机制，也是最直接、最常用的方式，就是简单地在函数或方法调用前加上
go
关键字。这会立即将该函数的执行调度到一个新的、轻量级的并发执行单元中，而不会阻塞当前的执行流。
解决方案
当你想让一个函数调用在后台，或者说以并发的方式运行，你只需要在调用它的前面加上
go
。这可以是任何普通的函数、方法，甚至是匿名函数。Go运行时会接管这个新创建的协程，并将其与其他的协程一起调度到可用的操作系统线程上。
package mainimport ( "fmt" "time")// 一个普通的函数func sayHello(name string) { time.Sleep(100 * time.Millisecond) // 模拟一些工作 fmt.Printf("Hello, %s!n", name)}func main() { fmt.Println("主协程开始...") // 使用 go 关键字启动一个协程来执行 sayHello go sayHello("Alice") // 启动一个匿名函数协程 go func(msg string) { time.Sleep(50 * time.Millisecond) fmt.Printf("匿名协程说: %sn", msg) }("你好") // 主协程继续执行，不会等待上面两个协程完成 fmt.Println("主协程继续执行...") // 为了让主协程有足够的时间等待其他协程完成，我们通常会引入同步机制 // 这里简单地等待一段时间，实际项目中会用 sync.WaitGroup 或 channel time.Sleep(200 * time.Millisecond) fmt.Println("主协程结束。")}
上面的例子清晰地展示了
go
关键字的用法。
sayHello("Alice")
和匿名函数都被
go
关键字包裹，它们会立即在各自的协程中开始执行。主协程不会等待它们，而是继续向下执行
fmt.Println("主协程继续执行...")
。这就是协程带来的非阻塞特性。
go
go
关键字到底做了什么，它和传统线程有什么本质区别？
从我的角度来看，
go
关键字是Go语言并发哲学的具体体现。它不仅仅是启动一个函数那么简单，它背后牵扯到Go运行时（runtime）一套精妙的调度机制。当你敲下
go
之后，Go运行时会创建一个新的协程，并把它放到一个等待执行的队列里。这个协程的初始栈空间非常小，通常只有几KB，这和操作系统线程动辄MB级别的栈空间形成了鲜明对比。
立即学习“go语言免费学习笔记（深入）”；
本质区别在于管理层面和资源开销：
管理层级： 传统线程是由操作系统内核调度的。每次线程切换、创建、销毁，都需要陷入内核态，开销较大。而Go协程则是由Go运行时在用户态进行调度的，它将大量的协程复用到少量（通常是
GOMAXPROCS
个）操作系统线程上。这种 M:N（多对多）的调度模型意味着Go运行时可以在用户态更快、更频繁地进行协程切换，而无需操作系统介入。资源开销： 协程的轻量级体现在其极小的内存占用和动态伸缩的栈。一个Go程序可以轻松地创建成千上万甚至上百万个协程，而不会像创建同等数量的OS线程那样迅速耗尽系统资源。OS线程通常有固定的、较大的栈空间，即使线程实际只使用了很小一部分，这部分内存也会被预留。上下文切换： 协程的上下文切换比OS线程快得多。因为所有的切换都在用户空间完成，不需要保存和恢复大量的寄存器状态，也不需要更新页表等。这让Go在处理高并发I/O密集型任务时表现得尤为出色。
所以，当我使用
go
关键字时，我心里清楚，我并不是在启动一个“笨重”的OS线程，而是在启动一个由Go运行时精心管理的“轻量级执行单元”，这让我能够更放心地去设计高度并发的程序，而不用过分担心性能瓶颈。
协程启动后，如何安全地与主协程通信或同步？
启动了协程，下一步自然是如何让它们协同工作，而不是各自为战。Go语言在这方面有一个非常核心的理念：“不要通过共享内存来通信，而是通过通信来共享内存。”（Don’t communicate by sharing memory; instead, share memory by communicating.）这句Go谚语指明了方向。
通道（Channels）： 这是Go语言推荐的、最地道的协程间通信方式。通道提供了一种类型安全的管道，允许不同协程之间发送和接收特定类型的值。
无缓冲通道： 发送和接收操作都是阻塞的，直到另一端准备好。它强制了协程间的同步。有缓冲通道： 允许在通道中存储一定数量的值，发送操作只有在通道满时才阻塞，接收操作只有在通道空时才阻塞。使用示例：
package mainimport ( "fmt" "time")func worker(id int, jobs <-chan int, results chan<- int) { for j := range jobs { fmt.Printf("Worker %d processing job %dn", id, j) time.Sleep(100 * time.Millisecond) // 模拟工作 results <- j * 2 // 发送结果 }}func main() { jobs := make(chan int, 5) results := make(chan int, 5) // 启动3个worker协程 for w := 1; w <= 3; w++ { go worker(w, jobs, results) } // 发送5个任务 for j := 1; j <= 5; j++ { jobs <- j } close(jobs) // 关闭jobs通道，告诉worker没有更多任务了 // 收集所有结果 for a := 1; a <= 5; a++ { <-results } fmt.Println("所有任务完成并结果已收集。")}
sync
包： 虽然Go提倡使用通道，但在某些特定场景下，传统的共享内存同步机制仍然是必要的，比如保护一个共享的数据结构不被并发修改。
sync.WaitGroup
： 用于等待一组协程完成。主协程调用
Add
来设置要等待的协程数量，每个协程完成时调用
Done
，主协程通过
Wait
阻塞直到所有协程都调用了
Done
。
sync.Mutex
和
sync.RWMutex
： 互斥锁，用于保护共享资源，确保在任何给定时刻只有一个协程可以访问该资源。
RWMutex
允许多个读操作并发进行，但在写操作时独占。
package mainimport ( "fmt" "sync" "time")func main() { var wg sync.WaitGroup var counter int var mu sync.Mutex // 保护 counter for i := 0; i < 5; i++ { wg.Add(1) // 每次启动一个协程，计数器加1 go func(id int) { defer wg.Done() // 协程完成时，计数器减1 time.Sleep(time.Duration(id) * 50 * time.Millisecond) mu.Lock() // 获取锁 counter++ fmt.Printf("协程 %d 增加了计数器，当前值: %dn", id, counter) mu.Unlock() // 释放锁 }(i) } wg.Wait() // 等待所有协程完成 fmt.Printf("所有协程完成，最终计数器值: %dn", counter)}
在我看来，通道是Go并发编程的“主菜”，它鼓励一种更高级别的抽象，让代码更易于理解和维护。而
sync
包则更像是“调味品”，在需要精细控制共享状态时发挥作用。
使用
go
go
关键字创建协程时，常见的陷阱和性能考量有哪些？
尽管
go
关键字用起来简单，但它背后隐藏的复杂性也可能带来一些棘手的问题，尤其是在处理并发时。我个人在实践中遇到过不少坑，这里总结一些常见的：
协程泄漏（Goroutine Leaks）： 这是最常见的陷阱之一。如果一个协程启动后，因为某些原因（比如等待一个永远不会发送数据的通道，或者没有正确处理错误导致提前退出，而其他协程还在等待其结果）而无法退出，它就会一直占用内存和CPU资源。即使主协程退出了，这些“僵尸”协程可能依然存在（如果程序没有完全终止）。这会导致内存占用持续增长，最终可能耗尽系统资源。
// 这是一个会发生协程泄漏的例子func leakExample() { ch := make(chan int) go func() { <-ch // 这个协程会一直阻塞在这里，因为没有人会向 ch 发送数据 }() // ch 永远不会被关闭或写入，上面的协程就永远不会退出 // 如果 leakExample 被反复调用，就会产生大量泄漏的协程}
解决这类问题通常需要仔细设计通道的关闭机制，或者使用
context
包来取消长时间运行的操作。
竞态条件（Race Conditions）： 当多个协程在没有适当同步的情况下，同时访问和修改共享资源时，就会发生竞态条件。结果往往是不可预测的，且难以复现和调试。Go提供了
go run -race
工具来帮助检测这类问题。
// 经典的竞态条件示例var globalCounter intfunc increment() { globalCounter++ // 这里没有锁保护，多个协程同时操作会导致错误}func main() { var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() increment() }() } wg.Wait() fmt.Printf("最终计数器: %d (可能不是1000)n", globalCounter)}
修复方案通常是使用
sync.Mutex
或
sync.RWMutex
来保护共享变量，或者更倾向于使用通道来传递数据而非直接共享。
循环变量捕获问题： 在循环中启动协程时，如果协程内部引用了循环变量，它可能会捕获到循环变量的最终值，而不是每次迭代时的值。这是因为协程是异步执行的，当它们真正执行时，循环可能已经结束了。
func main() { var wg sync.WaitGroup for i := 0; i < 5; i++ { wg.Add(1) go func() { defer wg.Done() time.Sleep(10 * time.Millisecond) fmt.Println(i) // 错误：所有协程可能都打印 5 }() } wg.Wait()}
正确的做法是： 将循环变量作为参数传递给协程，或者在循环内部创建一个新的局部变量来捕获当前值。
func main() { var wg sync.WaitGroup for i := 0; i < 5; i++ { wg.Add(1) // 方法一：作为参数传递 go func(val int) { defer wg.Done() time.Sleep(10 * time.Millisecond) fmt.Println(val) }(i) // 将 i 的当前值作为参数传入 // 方法二：创建局部变量 // iCopy := i // go func() { // defer wg.Done() // time.Sleep(10 * time.Millisecond) // fmt.Println(iCopy) // }() } wg.Wait()}
过多的协程： 尽管协程很轻量，但它们也不是免费的。创建过多的协程仍然会增加内存开销（每个协程都有一个栈）和调度器的负担。如果你的程序需要处理海量的、非常短生命周期的任务，可以考虑使用协程池来复用协程，而不是每次都创建新的。
协程内部的 Panic： 如果一个协程内部发生了 panic，并且没有被
recover
捕获，那么整个程序都会崩溃。在关键的、可能发生 panic 的协程中，通常会使用
defer
语句配合
recover
来捕获并处理错误，防止整个应用崩溃。
func mightPanic() { // 模拟一个可能发生 panic 的操作 panic("Something went terribly wrong in a goroutine!")}func main() { var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() defer func() { if r := recover(); r != nil { fmt.Printf("协程捕获到 panic: %vn", r) } }() mightPanic() fmt.Println("这行不会被执行") }() wg.Wait() fmt.Println("主协程继续执行，程序没有崩溃。")}
这些问题在并发编程中是普遍存在的，而
go
关键字只是提供了一个启动并发单元的入口。真正的挑战在于如何合理地设计协程间的通信和同步，以及如何优雅地处理错误和资源管理。
以上就是Golang协程创建方式 go关键字使用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1400535.html
微信扫一扫 
支付宝扫一扫 
