Go复习笔记：Goroutine与Channel协同工作（解决加锁加休眠隐患）
在之前的Go并发复习中，我通过阶乘案例重点剖析了“全局变量加锁同步”的诸多弊端，尤其是“加锁加休眠仍有隐患”这一核心问题——手动设置休眠时间无法精准匹配协程执行节奏，过长浪费资源、过短导致结果丢失，即便双重加锁也难以彻底规避资源竞争风险。本次复习我聚焦Goroutine与Channel的协同工作，通过一个完整实操案例，巩固二者结合的核心逻辑，彻底解决此前遗留的并发同步隐患，同时复盘协程与管道协同的关键细节，夯实自己的并发编程基础。
一、复习核心目标：解决“加锁加休眠”的固有隐患
回顾上一轮阶乘案例的复习，我发现：使用全局变量加锁同步实现多Goroutine通信时，最大的痛点是“主线程与协程的同步问题”。为了让主线程等待协程完成任务，我不得不手动添加time.Sleep()休眠，但这种方式完全依赖主观估算，无法适配实际运行中的系统负载、任务复杂度变化，本质上是一种“治标不治本”的解决方案。
而Goroutine与Channel的协同，正是Go语言为解决这一问题提供的原生方案——无需手动加锁（Channel本身并发安全），无需手动休眠（借助Channel的阻塞特性实现精准同步），让多协程之间的通信与同步更高效、更安全、更灵活。本次复习我的核心目标，就是通过实操案例，吃透二者协同的底层逻辑，彻底解决“加锁加休眠仍有隐患”的问题。
二、协同案例需求与思路拆解（个人复习复盘）
本次我选取的协同案例，是最基础也最具代表性的“生产者-消费者”模型简化版，需求明确且贴合实际，能够快速串联Goroutine与Channel的核心用法，具体需求如下：
- 开启1个writeData协程，向intChan管道中写入50个整数（生产者）；
- 开启1个readData协程，从同一个intChan管道中读取数据（消费者）；
- 主线程必须等待writeData和readData两个协程全部完成工作后，才能正常退出，杜绝协程未执行完主线程就退出的问题。
站在个人复习的角度，这个案例的核心思路其实很清晰，本质是利用Channel的两大特性解决同步问题，我自己梳理了两点核心逻辑：
- 用intChan作为数据传递管道，实现writeData与readData两个协程之间的通信，无需共享全局变量，从根源上避免资源竞争，替代我此前使用的“全局变量+互斥锁”方案；
- 用exitChan作为信号同步管道，让readData协程在读取完所有数据后，向主线程发送“完成信号”，主线程通过监听exitChan的信号，精准等待所有协程完成，替代我此前使用的手动休眠方案。
这里我重点复盘一个细节：管道的关闭（close()）是协同工作的关键。writeData协程写入完所有数据后，必须关闭intChan，否则readData协程会一直阻塞在读取操作上，导致死锁；而exitChan的关闭则可根据需求选择，核心作用是向主线程传递“协程完成”的信号，确保主线程精准退出，这也是我此前复习中容易忽略的点。
三、完整代码实现与细节复盘
结合上述思路，我整理了完整的代码实现（沿用提供的案例代码），同时复盘其中的关键细节，记录自己复习时关注的重点：
package main
import (
"fmt"
// 此处无需引入time包，彻底摆脱手动休眠的依赖
)
// writeData 协程：向intChan写入50个整数（生产者）
func writeData(intChan chan int) {
// 循环写入50个整数，逻辑简单但需注意循环边界
for i := 1; i <= 50; i++ {
// 向管道写入数据，有缓冲管道会自动调节写入节奏
intChan <- i
fmt.Println("writeData ", i)
// 此处可注释time.Sleep，验证Channel的缓冲特性，无需手动控制写入速度
// time.Sleep(time.Second)
}
// 关键操作：写入完成后关闭管道，告知readData协程“数据已写完”
close(intChan)
}
// readData 协程：从intChan读取数据，读取完成后向exitChan发送信号（消费者）
func readData(intChan chan int, exitChan chan bool) {
// 无限循环读取管道数据，直到管道关闭且无数据可读
for {
// 核心语法：v接收数据，ok判断管道是否关闭（true=有数据/未关闭，false=管道关闭且无数据）
v, ok := <-intChan
if !ok { // 管道关闭且无数据，说明读取完成，退出循环
break
}
fmt.Printf("readData 读到数据=%v\n", v)
}
// readData 读取完数据后，即任务完成
exitChan <- true
// 关闭exitChan（可选，此处关闭是为了让主线程读取信号后正常退出，避免阻塞）
close(exitChan)
}
func main() {
// 创建两个管道
// 1. 创建数据管道intChan：有缓冲管道，容量设为10，平衡读写节奏
// 复盘：容量可根据实际需求调整，此处10足够承载writeData的写入速度，避免频繁阻塞
intChan := make(chan int, 10)
// 2. 创建信号管道exitChan：用于传递“协程完成”信号，容量设为1即可（仅需传递1个信号）
exitChan := make(chan bool, 1)
// 启动两个协程，共享同一个intChan，实现协同工作
go writeData(intChan)
go readData(intChan, exitChan)
// 主线程监听exitChan，等待readData协程发送完成信号，精准退出
// 复盘：此处替代了此前的time.Sleep，彻底解决休眠时间估算不准的问题
for {
_, ok := <-exitChan
if !ok { // exitChan关闭且无信号，说明所有协程都已完成
break
}
}
// 主线程退出前可添加提示，验证协同效果
fmt.Println("所有协程执行完成，主线程正常退出")
}
关键细节复盘（个人复习重点）
结合代码，我从自身复习视角，梳理了几个容易忽略但至关重要的细节，这些细节直接决定协程与管道协同的稳定性，也是我此前复习中踩过的坑：
细节1：管道的关闭时机与作用
writeData协程在写入完50个整数后，必须调用close(intChan)。我总结了原因：如果不关闭管道，readData协程会一直执行for循环，尝试从intChan中读取数据，当intChan中无数据时，会一直阻塞，最终导致整个程序死锁。
我自己补充复盘：close()仅能由“写方”调用，读方不能关闭管道；管道关闭后，仍可读取管道中剩余的数据，读取完后ok值会变为false，这是判断管道是否读取完成的核心依据，也是我需要牢记的语法细节。
细节2：exitChan的核心作用——替代手动休眠
我梳理出exitChan的核心作用：实现“主线程与协程的精准同步”。readData协程读取完所有数据后，向exitChan写入true，主线程通过监听exitChan的信号，确认readData协程完成；而writeData协程的完成，由intChan的关闭间接确认（readData能读取完所有数据，说明writeData已写入完成并关闭管道）。
这就彻底解决了我此前遇到的“加锁加休眠”隐患——无需估算协程执行时间，主线程仅在收到“完成信号”后才退出，既不浪费资源，也不会导致协程未执行完就被销毁，这也是Channel相比全局变量加锁的核心优势之一。
细节3：有缓冲管道的选择与优势
本次案例中，intChan设置为容量10的有缓冲管道，而非无缓冲管道。我复盘后总结：有缓冲管道的优势在于“平衡读写节奏”——writeData可以一次性写入多个数据（不超过容量），无需等待readData立即读取；readData可以根据自身节奏读取数据，避免频繁阻塞。
我自己测试过，若改为无缓冲管道，writeData写入数据时会直接阻塞，直到readData读取数据后才能继续写入，虽然也能实现协同，但效率会降低，更适合对数据实时性要求极高的场景，这点我也记录在了自己的复习笔记中。
细节4：协程与管道的绑定逻辑
两个协程操作的是同一个intChan，这是协程间通信的核心——Channel作为“桥梁”，实现了数据的安全传递，无需共享全局变量，也就无需手动添加互斥锁，从根源上避免了资源竞争问题。这正是Channel相比“全局变量+加锁”的核心优势，也是我本次复习需要重点巩固的核心逻辑。
四、运行结果与问题验证
我运行了上述代码，整理出核心运行结果（截取部分），方便自己后续回顾：如图1
/app/go-atguigu/channel-apply # go run main.go
writeData 1
writeData 2
writeData 3
writeData 4
writeData 5
writeData 6
writeData 7
writeData 8
writeData 9
writeData 10
writeData 11
readData 读到数据=1
readData 读到数据=2
readData 读到数据=3
readData 读到数据=4
readData 读到数据=5
readData 读到数据=6
readData 读到数据=7
readData 读到数据=8
readData 读到数据=9
readData 读到数据=10
readData 读到数据=11
readData 读到数据=12
writeData 12
writeData 13
writeData 14
writeData 15
writeData 16
writeData 17
writeData 18
writeData 19
writeData 20
writeData 21
writeData 22
writeData 23
readData 读到数据=13
readData 读到数据=14
readData 读到数据=15
readData 读到数据=16
readData 读到数据=17
readData 读到数据=18
readData 读到数据=19
readData 读到数据=20
readData 读到数据=21
readData 读到数据=22
readData 读到数据=23
readData 读到数据=24
writeData 24
writeData 25
writeData 26
writeData 27
writeData 28
writeData 29
writeData 30
writeData 31
writeData 32
writeData 33
writeData 34
writeData 35
readData 读到数据=25
readData 读到数据=26
readData 读到数据=27
readData 读到数据=28
readData 读到数据=29
readData 读到数据=30
readData 读到数据=31
readData 读到数据=32
readData 读到数据=33
readData 读到数据=34
readData 读到数据=35
readData 读到数据=36
writeData 36
writeData 37
writeData 38
writeData 39
writeData 40
writeData 41
writeData 42
writeData 43
writeData 44
writeData 45
writeData 46
writeData 47
readData 读到数据=37
readData 读到数据=38
readData 读到数据=39
readData 读到数据=40
readData 读到数据=41
readData 读到数据=42
readData 读到数据=43
readData 读到数据=44
readData 读到数据=45
readData 读到数据=46
readData 读到数据=47
readData 读到数据=48
writeData 48
writeData 49
writeData 50
readData 读到数据=49
readData 读到数据=50
/app/go-atguigu/channel-apply #
所有协程执行完成，主线程正常退出
从运行结果中，我验证了以下几点，也进一步巩固了知识点：
- writeData协程成功写入50个整数，readData协程成功读取所有数据，二者协同正常，达到了预期效果；
- 主线程没有添加任何手动休眠，仅通过监听exitChan的信号，就实现了等待两个协程完成后再退出，彻底解决了我此前“休眠时间估算不准”的隐患；
- 整个过程无需手动加锁，没有出现任何资源竞争报错，印证了Channel的并发安全特性，也让我更坚信Channel在并发编程中的实用性。
我还做了补充测试：若注释掉writeData协程中的close(intChan)，运行后会触发死锁——readData协程会一直阻塞在读取操作上，exitChan无法收到完成信号，主线程也会一直阻塞，这也再次验证了“管道关闭时机”的重要性，也让我加深了对这一细节的记忆。
五、复习总结与核心收获
本次通过Goroutine与Channel的协同案例复习，我不仅巩固了二者的基础用法，更重要的是彻底解决了此前阶乘案例中“加锁加休眠仍有隐患”的核心问题，结合自身复习情况，梳理出以下核心收获：
- Goroutine与Channel的协同，是我目前掌握的Go并发编程最优方案之一——Channel实现协程间安全通信，无需共享全局变量和手动加锁；其阻塞特性实现协程与主线程的精准同步，无需手动休眠，从根源上规避了同步隐患，解决了我此前的核心痛点。
- 管道的关闭（close()）是协同工作的关键，写方完成写入后必须关闭管道，否则读方会一直阻塞，导致死锁；读方通过“v, ok := <-chan”判断管道是否关闭，是实现协同退出的核心语法，这是我本次复习重点记忆的细节。
- 有缓冲与无缓冲管道的选择，需结合实际场景，我自己总结了适配场景：有缓冲管道适合平衡读写节奏，提升效率；无缓冲管道适合实时性要求高的场景，实现读写“同步阻塞”，后续开发中可根据需求灵活选择。
- 对比我此前使用的“全局变量+加锁”方案，Channel的优势不仅在于简化代码、避免资源竞争，更在于其“精准同步”的能力，让并发程序更稳定、更可维护，这也让我更深刻理解了Go语言“通过通信来共享内存”的设计哲学。
本次复习我已完成Goroutine与Channel协同的核心实操，成功解决了遗留的并发同步隐患。后续我将继续复盘更复杂的协同场景（如多生产者、多消费者模型），进一步深化对Channel高级用法的理解，确保在实际开发中能够灵活运用二者，写出高效、安全的并发代码，夯实自己的Go并发编程核心基础。
