Why does the Goroutine (co-process) handle large concurrency?

This is a creation in Article, where the information may have evolved or changed.

Simply put: The process is very lightweight and can be executed in a single session with a total of 100,000, and still remain high performance.

Relationships and differences between processes, threads, and co-routines:

• The process has its own independent heap and stack, neither sharing the heap nor sharing the stack, and the process is dispatched by the operating system.

• Threads have their own separate stacks and shared heaps, shared heaps, non-shared stacks, and threads are also dispatched by the operating system (standard threads Yes).

• The threads share the heap as a thread and do not share the stack, and the process is displayed by the programmer in the code of the coprocessor.

Heap and stack differences see: http://www.cnblogs.com/ghj1976/p/3623037.html

The difference between a process and a thread is that the process avoids meaningless scheduling, which can improve performance, but therefore the programmer must assume responsibility for the dispatch itself.

The execution process requires very little stack memory (presumably 4~5kb), and by default, the size of the line stacks is 1MB.

Goroutine is a piece of code, a function entry, and a stack assigned to it on the heap . So it's very cheap, we can easily create tens of thousands of goroutine, but they are not scheduled to be executed by the operating system.

As with all other concurrent frames, the "no lock" advantage in Goroutine is only valid on a single thread, and if $gomaxprocs > 1 and communication between the threads is required, the Go runtime is responsible for lock-protected data. This is why sieve.go such an example is slower in multi-CPU multi-Threading.

http://my.oschina.net/Obahua/blog/144549

One of the main features of Goroutine is their consumption; The initial memory cost of creating them is very low (in stark contrast to traditional POSIX threads that require 1 to 8MB of memory) and the resources that are used to dynamically grow and shrink as needed. This allows goroutine to grow or reduce memory consumption from the initial stack memory footprint of 4096 bytes, without worrying about resource exhaustion.

To achieve this goal, the linker (5l, 6l, and 8l) inserts a preamble before each function, which checks to see if the current resource satisfies the need to invoke the function before the function is called (Note 1). If not, call Runtime.morestack to allocate a new stack page (note 2), copy the parameters of the function from the caller of the function, and then return control to the caller. At this point, the function can already be safely called. When the function is finished, the event does not end, and the function's return parameter is copied to the caller's stack structure, and the unused stack space is freed.

Through this process, the efficient implementation of the stack memory unlimited use. Let's say you're not constantly commuting between two stacks, and it's cheap to call it a stack split.

Resources:

"Translation" Why is the stack memory of Goroutine infinite?
http://my.oschina.net/Obahua/blog/144549

Understanding of processes, threads, and co-routines
Http://blog.leiqin.name/2012/12/02/%E8%BF%9B%E7%A8%8B%E3%80%81%E7%BA%BF%E7%A8%8B%E5%92%8C%E5%8D%8F%E7%A8%8B%E7 %9a%84%e7%90%86%e8%a7%a3.html

Stack size traps for the co-process framework
http://blog.csdn.net/huyiyang2010/article/details/6104891

Coroutine and its realization
Http://www.cnblogs.com/foxmailed/archive/2014/01/08.html

System knowledge Behind the Goroutine
http://www.sizeofvoid.net/goroutine-under-the-hood/