这是一个创建于 1372 天前的主题，其中的信息可能已经有所发展或是发生改变。
GC 会自动回收吗，有必要手动 close 吗，不 close 会有什么问题?
 |
1
selfeasy 2021-03-23 18:53:18 +08:00
不需要
通道是可以被垃圾回收机制回收的，它和关闭文件是不一样的，在结束操作之后关闭文件是必须要做的，但关闭通道不是必须的。 |
 |
2
hunk 2021-03-23 18:58:06 +08:00
不需要，取完了自然关闭。
话说我当初用协程，拼命想用上 channel，后来发现，不用也挺好，根本不需要哈。 |
 |
3
no1xsyzy 2021-03-23 22:15:11 +08:00
能不用 chan 就不用 chan，除非你清楚它的确能解决问题。
|
 |
4
dbow 2021-03-23 22:20:34 +08:00
channel 就是个普通对象， 不是文件，不需要关闭
|
 |
8
qq316107934 2021-03-24 11:51:35 +08:00  1
@no1xsyzy 解决 data race 问题首选 chan 吧，你这么说不太合适
|
|
9
no1xsyzy 2021-03-26 13:00:34 +08:00
@wellsc （你可能被降权了，我看到下面那个回复我才看到你的）
@qq316107934 https://linux.cn/article-12984-1.html 这是目前我看到的最全的讲 chan 的问题和陷阱的文章…… Data race 首选是 Mutex，效率高一个数量级。chan 还是需要锁的。乐观锁的情景就更不用说了。 |
|
10
qq316107934 2021-03-26 14:58:46 +08:00
@no1xsyzy
文章里的实例代码摆明了要按照其它语言的思想写 go：一边在吐槽 chan 缓冲区需要固定大小，一边吐槽不加缓冲区在 chan 外面加锁，会有可能因为 chan 阻塞引发哲学家就餐问题（ chan 是用来在一定程度上代替 mutex 的，混用就是容易造成死锁）；后面说会导致 goroutine 泄露的例子，也是用 context 的 deadline 就可以解决的。 个人不觉得是陷阱，是作者没有理解 chan 的正确用法和 pipeline 思想。追求绝对的效率用 mutex 没啥问题，但 chan 这么方便的东西，为啥要否定它呢？ btw,这篇文章看英文原版要比看中文容易，这个机翻太感人了... btw2,不是想争论谁更好用，是建议多去了解下 chan 的用法，新手建议先阅读这篇官博： https://blog.golang.org/pipelines |
|
11
no1xsyzy 2021-03-26 17:01:30 +08:00 via Android
@qq316107934 你得重新看一下
吐槽 chan 要固定大小说的是应当可以申请无限扩展的 chan |
|
12
no1xsyzy 2021-03-26 17:06:01 +08:00 via Android
@qq316107934 go routine 泄漏的例子不能简单地 deadline，因为玩家可能花费很久的时间产生一个新的分数。至于让 Player 也要求定期产生值就完全违背了接口设计，整个代码重新翻过。问题是不应当让 Game 变成一段主动运行的代码。而你要用 chan，必然产生主动运行的代码。
|
|
13
no1xsyzy 2021-03-26 17:22:10 +08:00 via Android
@qq316107934 至于死锁，其实是因为 chan 暗含了一个锁。你必然会发生需要锁而不是管道的情况。但 golang 暗锁的问题太容易撞新手盲区了。每个月你都能见到误用 chan 导致的问题。
golang 并没有实现真正的 pipelining 思想，你可以看看 ponylang 是怎么处理的，不是协程模式，而是 actor 模式。我相信 haskell 社区和 lisp 社区有更充分更健壮的实现方式。但拿 golang 说 pipelining 思想莫过于有些“年轻人的第一个 pipeline”味道了 |
Select Language