The Goroutine Model

<p>Hello, I&#39;m learning golang and I read that Goroutines are not real threads. The are managed and scheduled by the runtime, which makes them very efficient. So why don&#39;t other languages (e.g. Java) do this? Any downside of this model?</p> <hr/>**评论：**<br/><br/>Crast: <pre><p>There are other languages that do something similar to this. Stackless Python (or python with greenlets, such as gevent/eventlet) use a model very similar to this to run microthreads/coroutines that are not directly tied to OS threads (with key limitations due to the underlying language restrictions of Python, of course)</p> <p>I&#39;m going to answer your two questions in reverse as it will lead to the answer better:</p> <p>There are a lot of upsides as you may know, but the real downside of this model is that your coroutine scheduler in your language/runtime <strong>must</strong> be good and accurate to work alongside your operating system to ensure that coroutines that <em>need</em> to be scheduled are scheduled and run. There&#39;s often discussion of &#34;fairness&#34; as well, and over time/releases Go has improved on fairness of wakeup to improve the overall latency &#39;observed&#39;.</p> <p>Furthermore, with a &#34;bad&#34; scheduler there are possible negative implications on some hardware, if the scheduler is not aware of the cost of moving a coroutine across hardware boundaries such as across SMP CPUs, or across cores invalidating some of the caches, some workloads could work out to theoretically more expensive than letting the OS manage the threads.</p> <p>The good news is, the Goroutine scheduler is pretty good (but not perfect) on major architectures/OSes, and continues to improve with every major release.</p> <hr/> <p>So why don&#39;t other languages do this? Mostly, because it&#39;s <strong>hard</strong>. If you think of a huge ecosystem like Java and the JVM, with decades of history, you can&#39;t make a change in a sweeping way. Go had the advantage of having these primitives from the beginning, and also having a spec which is very carefully worded with regards to what is and isn&#39;t guaranteed in a given concurrency primitive (for example <a href="https://golang.org/ref/mem#tmp_2" rel="nofollow">https://golang.org/ref/mem#tmp_2</a> ).</p> <p>There are definitely inroads into concurrency models for some of these languages even still... for example in the JVM world, you have scala&#39;s Akka framework which re-conceptualizes how you think about concurrency, but in a way which is still friendly to typical java code... you can get big concurrency, but you have to either specify constraints (execution contexts/threadpools) or code very carefully in some of these contexts to make sure you don&#39;t accidentally block an actor.</p></pre>kune13: <pre><p>Other languages have done it. Java&#39;s first multithreading implementation called Green Threads didn&#39;t rely on OS threads at all. The major problem with user-space threads are system calls that are blocking. Go mitigates the problem by starting new OS-Threads if a running thread is blocking and wrappers around network system calls that put a goroutine to sleep and wake before a read or write on a file descriptor. In go 1.9 this functionality is extended for file operations.</p></pre>