Go 语言 Channel 阻塞行为探究
在使用 Go 语言 Channel 时，缓冲区大小对读写操作的阻塞行为影响常常令人困惑。本文将深入探讨缓冲区大小为 0 时，写入操作为何并非总是立即阻塞的原因。
问题描述：
当使用 make(chan int, 0) 创建一个无缓冲 Channel 时，直觉上认为向其写入数据应该立即阻塞，因为没有缓冲空间。然而，实际测试中，第一次写入有时不会阻塞。
预期与实际结果对比：
预期：无缓冲 Channel 的第一次写入操作应立即阻塞。
实际：第一次写入可能不会阻塞，只有后续写入才会阻塞。
原因分析：
这种现象的关键在于 Goroutine 调度的不确定性以及读写操作的并发执行。如果读取操作先于写入操作执行，并且读取操作被阻塞等待数据，那么此时第一次写入操作将不会阻塞，因为写入操作可以立即将数据写入到空闲的 Channel 中。只有当 Channel 中没有读取操作，并且后续写入操作试图写入数据时，才会发生阻塞。
阻塞机制详解：
- 写入阻塞: 当 Channel 缓冲区已满，而 Goroutine 试图写入数据时，该 Goroutine 将被阻塞，直到有空间可用。
- 读取阻塞: 当 Channel 缓冲区为空，而 Goroutine 试图读取数据时，该 Goroutine 将被阻塞，直到有数据可用。
示例说明：
文中提供的示例输出：
<code>----0 0 ----1 1 ----2 2 ----3 3 ----4 4 ----5 5 ----6 6 ----7 7 ----8 8 ----9 9</code>
展示了读写操作交错执行的情况，这正是导致第一次写入不阻塞的原因。读写操作的执行顺序取决于 Goroutine 调度器，其结果并非总是确定的。
因此，在处理无缓冲 Channel 时，不能依赖于第一次写入操作一定会阻塞。 需要仔细考虑 Goroutine 的并发执行以及调度器的非确定性。
