Channel 的 size 要么是 1，要么是无缓冲的。这是否过于原教旨主义？

[xrefft]

Channel 的 size 要么是 1，要么是无缓冲的。这似乎很理想，然而大小为64和大小为1的channel，在工程实践上有又有多大的区别呢？

[xrefft]

在4并发下，不同大小channel的收发效率，可以看到，有缓冲的channel和无缓冲还是有很大的性能差距的。

BenchmarkChannel
BenchmarkChannel/n=4,chSize=0
BenchmarkChannel/n=4,chSize=0-12         	 5224874	       217.5 ns/op
BenchmarkChannel/n=4,chSize=1
BenchmarkChannel/n=4,chSize=1-12         	 7133804	       170.0 ns/op
BenchmarkChannel/n=4,chSize=2
BenchmarkChannel/n=4,chSize=2-12         	 7922356	       146.7 ns/op
BenchmarkChannel/n=4,chSize=4
BenchmarkChannel/n=4,chSize=4-12         	 9753764	       121.8 ns/op
BenchmarkChannel/n=4,chSize=8
BenchmarkChannel/n=4,chSize=8-12         	12045931	        99.45 ns/op
BenchmarkChannel/n=4,chSize=16
BenchmarkChannel/n=4,chSize=16-12        	14351455	        84.71 ns/op
BenchmarkChannel/n=4,chSize=32
BenchmarkChannel/n=4,chSize=32-12        	15173770	        75.19 ns/op
BenchmarkChannel/n=4,chSize=128
BenchmarkChannel/n=4,chSize=128-12       	18279938	        70.27 ns/op

肯定有人会说，工程时间里，这几纳秒的差距有那么重要么？但反过来说，既然不重要，编码规范里限制这么死的意义又在哪里呢？

诚然，我们不应该设计出动辄高达几万几十万大小buffer的chanel，但同时，在一些经验值大小下的channel（比如CPU核心数以内大小），分出精力探讨这个channel的buffer要有多大也是缺乏意义的。

我认为，“Channel 的 size 要么是 1，要么是无缓冲的。”这样的规范，体现的不过是设计者对于概念性的事物（”比如有或无“）的疯狂依恋。这种数字痴迷往往来自于缺乏工程实践的设计者，想通过一种形而上学的概念框定和管理一切事物，然而结果往往总是事与愿违。

[xxjwxc]

点赞，不过条目是死的，人是活的

[LL1024LL]

这条规则，我也是在阅读的时候留意了下。在实际工程运用的时候，也是觉得怪怪的。从使用方的角度我尝试的琢磨了一下原因：

从使用方来看，缓冲区size>1的时候，经验不丰富的开发者会潜意识的认为是数据投递到chan中是一个非阻塞操作，进而较大概率忽略缓冲区满，发生生产端阻塞的情况（有经验的开发者则不会），进而产生一些非预期的错误；而size <=1的时候，使用方在使用的时候，就会该操作大概率会发生阻塞的意识，进而做好容错处理；同时，如果业务场景不可接受生产端阻塞，也可以自行通过启动一个协程，来把数据放到chan中，实现非阻塞投递的效果。

从整个编程规范来看，很多措施都是提前将问题暴露出来，使得水平层次不齐的开发者，减少犯错的空间。以上是个人理解，不喜勿喷