当前位置：首页 > 编程日记 > 正文

Go语言的Channel文章，整个人都感觉不好了

编程日记 2024-06-19 17:40:00

链客，专为开发者而生，有问必答！

此文章来自区块链技术社区，未经允许拒绝转载。

在这里插入图片描述

Go的Channel是一个很强大的并发数据模型，在一个发送者和多个消费者情况下工作得最好，但是如果是多个发送者，那么在Channel关闭时需要协调多个发送者，等待它们发送消费完毕，同时也会导致一个Channel多次关闭的情况，这个问题Go社区已经注意到，并正在试图解决：issue#14601

让我们看看来自

go channels are bad and you should feel bad | jtol一文是如何抱怨Channel有多不好，以下是原文大意转述：

首先，不用质疑的是，该文博主自从2010中期就开始使用Go语言，参与编写了425K行的纯Go代码，并为Go社区提供了不少开源项目。

Go语言是以Channel和Goroutine（轻量线程）著称，它的理论模型主要是基于CSP模型（Communicating Sequential Processes），但是该文博主认为，从程序员角度看，Go的Channel模型实现方式是错误的，它是一个彻底的反模式。

CSP模型是一种高并发计算模型，这种模型本身是试图通过一个通道同步管理发送和接受，但是，如果一旦你引入其他同步机制如互斥锁mutex、semaphore或条件判断变量，你就再也不是纯的CSP了。

下面让我们看看使用GO编写CSP模型，这个案例是关于如何接受到选手的最高分。

首先，使用Game作为数据结构：

type Game struct {
bestScore int
scores chan int
}

这里状态变量bestScore 并不使用互斥锁进行保护，因为我们只有一个goroutine管理这个状态，新的分数是通过一个channel接受的。

func (g *Game) run() {
for score := range g.scores {
if g.bestScore < score {
g.bestScore = score
}
}
}

现在开始一个启动game的构造器：

func NewGame() (g *Game) {
g = &Game{
bestScore: 0,
scores: make(chan int),
}
go g.run()
return g
}

下一步，让我们假设有人给我们一个Player接口，这个接口可以获得分数score，也可能返回错误，因为也许网络连接错误或player已经退出。

type Player interface {
NextScore() (score int, err error)
}

下面是处理player，首先检查错误，然后将接受到的分数发给channel。

func (g *Game) HandlePlayer(p Player) error {
for {
score, err := p.NextScore()
if err != nil {
return err
}
g.scores <- score
}
}

好了，我们有一个Game类型，能够以线程安全方式跟踪Player的最高分。

当你将这个游戏上线运行后，你获得了非常地成功，你的游戏服务器上运行了很多这样的Game程序。但是你会发现人们有时会离开你的游戏，许多游戏里面没有任何玩家，但是游戏本身没有停止而是不停地在循环运行，你被(*Game).run协程搞得不知所措了。

其实这个案例完全可以不使用Channel简单地完成：

type Game struct {
mtx sync.Mutex
bestScore int
}

func NewGame() *Game {
return &Game{}
}

func (g *Game) HandlePlayer(p Player) error {
for {
score, err := p.NextScore()
if err != nil {
return err
}
g.mtx.Lock()
if g.bestScore < score {
g.bestScore = score
}
g.mtx.Unlock()
}
}

这里只是引入了互斥锁，替代了原来的Channel方式。使用传统的同步锁替代CSP的Go channel居然解决了问题。

那么，让我们看看Go语言的Channel背后是什么？Channel是使用锁保证连续访问的线程安全性，使用Channel同步化内存的访问，其实你是在使用锁(banq注：这违背了CSP模型本身定义，CSP存在的前提就是避免使用锁。)，锁被线程安全的队列给包装了，那么Go的这个神秘的锁与直接使用标准库中mutex有什么区别？下面是两者性能测试结果：

BenchmarkSimpleSet-8 3000000 391 ns/op
BenchmarkSimpleChannelSet-8 1000000 1699 ns/op

对于unbuffered channel也是同样测试结果。(测试结果表明：Channel性能比mutex性能要差得多)

也许Go的调度器会提高，但是这意味着老的旧的互斥锁和条件变量表现得非常好，更有效，更快速。如果你需要性能，那么就使用这些真正的方法（互斥锁等方法）。

此后，该文作者还指出Channel其实并不能和其他并发原始模型很好地组合在一起。比如Channel和互斥锁放在一起就带来不确定性。

他还指出，在API中使用Channel反而使得问题变得糟糕，你完全可以在没有任何协程情况下使用互斥锁mutexe, semaphores,和回调callbacks编写API，有时，回调函数反而更加强大，虽然，goroutine协程口口声声说是用来替代万恶的回调函数的。协程只是比线程较为轻量，但是较为轻量不代表它是最轻量的。

他还谈到：对一个已经关闭的Channel再进行关闭或发送操作是非常痛苦，如果你要关闭一个Channel，需要将关闭状态进行同步化操作，使用mutex互斥锁等，但是它们又不能很好地协调在一起，为什需要有关闭的状态？因为这样才会防止其他写入者同时写入或关闭一个已经关闭的channel。

https://www.dkcj.cn/info/11425.html

Go语言的Channel文章，整个人都感觉不好了

相关文章：

图书管理系统（源码）

linux 如何禁用账号和解除禁用账号

maya批量命名插件_教你玩转MAYA的四十二精华造诣（第一期）

Go语言开发常见陷阱，你遇到过几个？

sxoi爆炸祭

wiki多个文件一起导入_mac文件信息管理工具EagleFiler for Mac分享给大家

【bzoj1951】 Sdoi2010—古代猪文

区块链之智能合约详解

子类化内置类型

网上商城系统源代码_多用户系统商城授权有几种方式？

java学习：对synchronized的测试

Selenium（3）

php 爬虫_Rad爬虫结合W13Scan扫描器挖掘漏洞

Python 爬取网页HTML代码

区块链兼容以太坊智能合约

Linux常用命令--网终设置

python示例异常处理与程序调试_笔记：Python异常处理与程序调试

js传入参数为字符串问题

区块链热度背后的资本市场

袋鼠过河（动态规划）

jenkins-svn配置

python查看所有异常_如何获取python异常发生的实际行号？

区块链从一夜暴富到一夜暴“负”的辛酸史

iOS消息转发

python参数类型限定_python限定方法参数类型、返回值类型、变量类型等|python3教程|python入门|python教程...

CentOS VMware 配置IP小结静态配置桥接 NAT

区块链简史：解读这场技术革命的前世今生

IncDec Sequence（codevs 2098）

C++ 中set

python自动排课表_【python-leetcode210-拓扑排序】课程表Ⅱ