go语言无缓冲的channel无缓冲的通道（unbuffered channel）是指在接收前没有能力保存任何值的通道 。
这种类型的通道要求发送goroutine和接收goroutine同时准备好，才能完成发送和接收操作 。否则，通道会导致先执行发送或接收操作的 goroutine 阻塞等待 。
这种对通道进行发送和接收的交互行为本身就是同步的 。其中任意一个操作都无法离开另一个操作单独存在 。
阻塞：由于某种原因数据没有到达 ， 当前协程（线程）持续处于等待状态，直到条件满足，才接触阻塞 。
同步：在两个或多个协程（线程）间，保持数据内容一致性的机制 。
下图展示两个 goroutine 如何利用无缓冲的通道来共享一个值：
在第 1 步 ， 两个 goroutine 都到达通道 ， 但哪个都没有开始执行发送或者接收 。
在第 2 步，左侧的 goroutine 将它的手伸进了通道，这模拟了向通道发送数据的行为 。这时，这个 goroutine 会在通道中被锁住 ， 直到交换完成 。
在第 3 步，右侧的 goroutine 将它的手放入通道，这模拟了从通道里接收数据 。这个 goroutine 一样也会在通道中被锁住，直到交换完成 。
在第 4 步和第 5 步，进行交换，并最终 ， 在第 6 步，两个 goroutine 都将它们的手从通道里拿出来，这模拟了被锁住的 goroutine 得到释放 。两个 goroutine 现在都可以去做别的事情了 。
如果没有指定缓冲区容量，那么该通道就是同步的，因此会阻塞到发送者准备好发送和接收者准备好接收 。
无缓冲channel： —— 同步通信
驳狗屎文 "我为什么放弃Go语言此篇文章流传甚广, 其实里面没啥干货，而且里面很多观点是有问题的. 这个文章在 golang-china 很早就讨论过了.
最近因为 Rust 1.0 和 1.1 的发布, 导致这个文章又出来毒害读者.
所以写了这篇反驳文章, 指出其中的问题.
有好几次，当我想起来的时候，总是会问自己：我为什么要放弃Go语言？这个决定是正确的吗？是明智和理性的吗？其实我一直在认真思考这个问题 。
开门见山地说，我当初放弃Go语言（golang），就是因为两个“不爽”：第一，对Go语言本身不爽；第二 ， 对Go语言社区里的某些人不爽 。毫无疑问，这是非常主观的结论 。但是我有足够详实的客观的论据，用以支撑这个看似主观的结论 。
文末附有本文更新日志 。
确实是非常主观的结论, 因为里面有不少有问题的观点(用来忽悠Go小白还行).
第0节：我的Go语言经历
先说说我的经历吧，以避免被无缘无故地当作Go语言的低级黑 。
2009年底，Go语言（golang）第一个公开版本发布，笼罩着“Google公司制造”的光环 ， 吸引了许多慕名而来的尝鲜者 ， 我（Liigo）也身居其中，笼统的看了一些Go语言的资料 ， 学习了基础的教程，因对其语法中的分号和花括号不满，很快就遗忘掉了 ， 没拿它当一回事 。
在2009年Go刚发布时, 确实是因为“Google公司制造”的光环而吸引了(包括文章作者和诸多IT采访人员)很多低级的尝鲜者.
还好, 经过5年的发展, 这些纯粹因为光环来的投机者所剩已经不多了(Google趋势).
目前, 真正的Go用户早就将Go用于实际的生产了.
说到 其语法中的分号和花括号不满, 我想说这只是你的 个人主观感受, 还有很多人对Go的分号和花括号很满意,
包括水果公司的的 Swift 的语言设计者也很满意这种风格(Swift中的分号和花括号和Go基本相同).
如果只谈 个人主观感受, 我也可以说 Rust 的 fn 缩写也很蛋疼!
两年之后，2011年底，Go语言发布1.0的计划被提上日程，相关的报道又多起来，我再次关注它，重新评估之后决定深入参与Go语言 。我订阅了其users、nuts、dev、commits等官方邮件组 ， 坚持每天阅读其中的电子邮件，以及开发者提交的每一次源代码更新 ， 给Go提交了许多改进意见，甚至包括修改Go语言编译器源代码直接参与开发任务 。如此持续了数月时间 。
推荐阅读
- oracle数据类型界面，oracle 类型
- mysql数据至es，mysql转es
- 普通话如何推广的书，推广普通话文件资料汇编书籍
- 河北电商订水软件代理商，河北电商
- java论坛代码 java代码交流网站
- 公众号的商户号怎么改绑，商户公众号怎么做
- java爬虫429状态码的简单介绍
- PHP解决大量数据循 php yield 处理大数据
- chatgpt聊天发不出去，聊天信息发不出去是怎么回事