2016-04-12 8 views
1

Hier ist der Code. In der golang Hauptfunktion, die in main.goSpeicherverluste in Golang

func main() { 
    rgc.GetRgcService() 
} 

wo die rgc in einer anderen golang Datei ist, mrgc.go benannt. Der Code innerhalb ist

package rgc 
func GetRgcService() (svc *RgcService, err error) {} 

Die Funktion GetRgcService ist eine leere Funktion.

Allerdings, wenn ich valgrind verwendet, um den Speicher zu testen, habe ich die folgende Ausgabe

==58156== HEAP SUMMARY: 
==58156==  in use at exit: 1,152 bytes in 4 blocks 
==58156== total heap usage: 9 allocs, 5 frees, 1,304 bytes allocated 
==58156== 288 bytes in 1 blocks are possibly lost in loss record 4 of 4 
==58156== at 0x4A27F63: calloc (vg_replace_malloc.c:593) 
==58156== by 0x4010DE1: allocate_dtv (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so) 
==58156== by 0x40114ED: _dl_allocate_tls (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so) 
==58156== by 0x4B36DE2: [email protected]@GLIBC_2.2.5 (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/libpthread-2.18.so) 
==58156== by 0x4B2937: _cgo_sys_thread_start (gcc_linux_amd64.c:75) 
==58156== by 0x45506C: runtime.asmcgocall (/home/map/.jumbo/lib/go/src/runtime/asm_amd64.s:612) 
==58156== by 0x50619F: ??? (in /home/users/zhanghuaizhi/ttt.38) 
==58156== by 0xC7FFFFFFFF: ??? 
==58156== by 0xC820067FFF: ??? 
==58156== by 0x42D69B: runtime.allocm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1260) 
==58156== by 0x42DD3A: runtime.newm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1510) 
==58156== by 0x42E071: runtime.startm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1583) 
==58156== 
==58156== LEAK SUMMARY: 
==58156== definitely lost: 0 bytes in 0 blocks 
==58156== indirectly lost: 0 bytes in 0 blocks 
==58156==  possibly lost: 1,152 bytes in 4 blocks 
==58156== still reachable: 0 bytes in 0 blocks 
==58156==   suppressed: 0 bytes in 0 blocks 

Wie kann ich diese Speicher frei? Da muss ich mit dieser Funktion viel arbeiten. Es verursacht viele Speicherlecks, die nicht freigegeben werden können

+4

Go ist Speicher verwaltet und Garbage gesammelt, so gibt es keine Möglichkeit, Speicher manuell freizugeben. und deswegen bin ich mir nicht sicher, ob ich Go-Apps mit Valgrind untersuchen kann. –

+0

@Not_a_Golfer 'Valgrind' ist ein leistungsfähiges Speichertestwerkzeug. Sie können versuchen – Wyatt

+6

@Wyatt Sein Punkt ist, dass Valgrind auf Go-Programmen nutzlos ist. Es weiß nicht, wie Go den Speicher verwaltet. Go verwendet nicht malloc/free (außer in einigen seltenen Fällen, in denen die Standardbibliothek verwendet werden muss, wie hier), was valgrind außer Kraft setzt, um Speicherzuweisungen zu kennen. – Art

Antwort

13

Nichts wurde durchgesickert. Der Speicher ist immer noch erreichbar und es ist durchaus üblich, Dinge beim Beenden nicht freizugeben, es braucht nur unnötige Zeit und das OS wird sich trotzdem darum kümmern.

Dies ist Speicher reserviert lokalen lokalen Speicher zu einem Thread, der noch läuft, so dass es falsch wäre, es freizugeben. Eine bessere Frage wäre "Wie stoppe ich diesen Thread?", Auf die eine Antwort lautet: Sie tun es nicht, die Go-Laufzeit behandelt sie. Es ist durchaus üblich, Threads beim Beenden nicht zu stoppen, es braucht nur unnötige Zeit und das OS wird sich trotzdem darum kümmern.

Es hat nichts mit Ihrem Code und Ihrem Funktionsaufruf zu tun, es ist etwas, das Go Runtime für sich selbst zuweist.

Go ist eine Müll-Sprache und die Verwendung von Valgrind darauf wird Ihnen nicht viel sagen. Es wird weder echte Speicherlecks erkennen, noch wird es verstehen, welcher Speicher noch verwendet wird.

0

Sie können manuell Garbage Collection laufen: https://golang.org/pkg/runtime/#GC

denke ich, dass der Speicher frei würde, aber wie andere schon gesagt haben, dass der Speicher schließlich befreit werden, wenn die geplante Garbage Collector läuft der Laufzeit.