Is it true that long running goroutine are an issue?

<p>I heard that many times, is it true and if it&#39;s the case what&#39;s the reason and also how to avoid that in our code?</p> <p>Thank you,</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>The issue you might be referring to is leaking goroutines, i.e. goroutines that are blocked on a communication that can never succeed (for example they try to write to a channel whose reading end fell out of scope). And yes, if that happens, it&#39;s an issue. The issue is basically what a memory leak is in the C/Java/Python world. It&#39;s the one thing that makes writing concurrent software in go tricky-ish. Though it&#39;s still far less likely than just a memory leak.</p></pre>robertmeta: <pre><blockquote> <p>I heard that many times</p> </blockquote> <p>Consider anyplace that says that a &#34;poor source&#34; for Go knowledge.</p> <blockquote> <p>is it true</p> </blockquote> <p>Not even a little bit. </p></pre>yimmy149: <pre><p>I have a Go process with 252 days of up-time, it has several long running go routines, no problems.</p></pre>SportingSnow21: <pre><p>There&#39;s a &#34;perfect storm&#34; mix that can create issues:</p> <ul> <li>Multiple long-running goroutines</li> <li>Without any blocking calls (I/O, channel, syscalls, function calls in general)</li> <li>Running on a small number of cores </li> <li>Generating lots of garbage</li> </ul> <p>Combined, this will mess with the runtime (scheduler and GC) to cause rough performance. These situations are rare and usually are a result of terrible design and no refactoring. It&#39;s, more-or-less, a subset of the &#34;bad code is bad and you should feel bad&#34; lemma.</p></pre>_nefario_: <pre><p>no. </p> <p>i don&#39;t know where you heard this many times, because i&#39;ve been reading up on go intensely for several months and i haven&#39;t heard this even once. i even work with people who would love nothing more than to shit on go, but even they haven&#39;t mentioned anything about this.</p></pre>