TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Buffered Channels in Go: Tips and Tricks

67 点作者 i_have_to_speak超过 7 年前

4 条评论

cjslep超过 7 年前
All of these tricks work with unbuffered channels as well. So it leaves the far more interesting question &quot;When do you use buffered or unbuffered channels?&quot; unanswered. Naturally, it depends a lot on the kind of system you want to build. Amking a channel buffered exposes the performance pitfall where a slow consumer is masked or hidden until it&#x27;s supplier fills the buffer, and the real throughput is then exposed.<p>Edit: An interesting application of a buffered channel, for example, is when creating an object pool of finite size. Or, in conjunction with a timer, rate limiting a piece of code. I don&#x27;t think I have ever considered a buffered channel in the typical producer&#x2F;consumer setup.
评论 #16150377 未加载
评论 #16150971 未加载
shabbyrobe超过 7 年前
Channels can be really useful but are massively oversold. Fortunately it has cooled off a bit in recent years but I still see heaps of go code that bends over backwards to use channels because &quot;share memory by communicating blah blah blah&quot;, even in cases where using another synchronisation mechanism instead would radically simplify things.
rplnt超过 7 年前
&gt; If you do have pointers, or if the item iself [sic] is a pointer, it is up to you to ensure that the pointed-to objects remain valid while it is in the queue and being consumed.<p>Does this mean the producer have to keep pointer for the queued item around or it could get garbage collected? That seems.. unintuitive? Or is it just that working with the object could make the old pointer invalid?
评论 #16150563 未加载
innagadadavida超过 7 年前
Interesting read. There are instances when you need unlimited capacity, and there is a proposal for it: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;20352" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;20352</a> It doesn’t look like it will make it as the maintainers are opposed to it.