This is the 13th day of my participation in Gwen Challenge

How do I know if a variable is on the heap or on the stack?

You don’t really care where the variables are, exactly. There is mainly a reference to a variable, so it must exist. Exactly where it exists depends on how each language is implemented.

Where variables exist does affect the efficiency of a program. The Go compiler places local variables in a function on the stack, but if the compiler cannot ensure that the variable will be referenced somewhere when the function returns, it places the loop in the garbage collector heap to avoid dangling pointer errors. Also, if the local variable is large, it makes more sense to put it on the heap than on the stack.

In current implementations of compilers, if a variable occupies an address, it is eligible for allocation to the heap, but under basic “escape analysis,” the variable is returned to the heap at some point after the function is finished executing.

Correctness of standpointCopy the code

What operations are atomic? What was Mutexes like?

A detailed description of Go’s operation atomicity can be found at this link: golang.org/ref/mem

Low-level implementations of synchronization and raw atomic operations can use the sync and sync/atomic packages. These packages are useful for simple tasks such as auto-increment or small-scale interlocking.

Advanced operations, such as writing between concurrent servers, use advanced techniques to make programs run better. Go is achieved through channels. For example, you could design your program so that only one coroutine processes a block of data at a given moment, and no other coroutine can touch the data. You can see the original summary document: www.youtube.com/watch?v=PAA…

Different programs do not communicate by sharing memory data, but by sharing memory data by common consent.

Check out this article to learn how to share memory via communication golang.org/doc/codewal…

Large-scale concurrent programs use these toolsets similarly.