Application of Golang 1.2.1 in production environment should pay attention to the problems

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

Golang 1.2.1 GC Because of the problem of the algorithm, in the actual application process, for a long-running daemon program, it is very easy to lead to memory leaks, some people use CGO to manually manage the memory, some people use pool to manage the buffer, these are very troublesome, or wait 1.3 released it, in In Golang 1.2.1, it is easy to write a stable running program if you are aware of some pits.

1. Avoid recursion;

2. In for, some of the repeated operations mentioned outside, such as the Init method of the package execution, these do not need to say, such as the initialization of a database connection, regexp.compile, etc.

3. function returns, for slice itself is a reference pass, struct and other relatively large objects, with pointers, in the for loop inside the pointer is used to assign a value of nil, this is very important;

The garbage collector would collect memory your program no longer have a pointer to. To avoid leaking memory you just need to avoid holding on to pointers to memory you ' re no longer interested in using.

4. Note Some of the wrong wording, such as:

Func parsefile (file string) string {
F, err: = OS. Open (file)

Defer F.close ()
If err! = Nil {
Fmt. PRINTLN (ERR)
Os. Exit (1)
}

The correct wording is:

Func parsefile (file string) string {
F, err: = OS. Open (file)
If err! = Nil {
Fmt. PRINTLN (ERR)
Return ""
Os. Exit (1)
}else{
Defer F.close ()
}

This problem many beginners easy to commit, very easy to lead to CPU consumption, or even error;

5. Reduce the creation of objects, use arrays as far as possible, structs can be used as linked lists;

6. Runtime. GC () No use, go every 2 minutes to perform garbage collection;

> What's it used for? It should use of what situation?

For example, before running a benchmark. but the runtime was free to
ignore the call or postpone performing the real GC to any later time
So it's a hint at best.

> It is useful to avoid memory leaks?

No. But it can in theory exchange longer GC pauses for more shorter
ones and also lower the total used memory-for some programs and it
May is a win for them.

See also:http://golang.org/pkg/runtime/ debug/#FreeOSMemory  

7. The program finishes running for a period of time, with go own performance analysis tool PPROF analysis Heap,cpu, and so on, find the problem as soon as possible;

8. Run to find high CPU consumption, memory continues to rise how to do, write a program timed killall, or crontab execution, and then slowly tuning;