Was sind die Ursachen für Golang-Speicherlecks?

Die Gründe für das Leck sind: 1. Die Verwendung von time.After(duration x) generiert NewTimer(), bevor die Dauer x abläuft , GC; 2. time.NewTicker-Ressourcen werden nicht rechtzeitig freigegeben; 4. Kanalblockierung; 6. verursacht durch Slice;

Die Betriebsumgebung dieses Tutorials: Windows 7-System, GO Version 1.18, Dell G3-Computer.

Mehrere Situationen, in denen Golang leicht zu Speicherverlusten führen kann

1. Unsachgemäße Verwendung von Timern

1.1 Die Verwendung von time.After()

Die Standardeinstellung time.After() hat Speicher Das Problem ist durchgesickert, da NewTimer() jedes Mal generiert wird.After(Dauer

Mit der Zeit vergeht, insbesondere wenn die Dauer abnimmt. Bitte überprüfen Sie den Unterschied selbst oder lesen Sie meine vorherigen Artikel https://blog.csdn.net/weixin_38299404/article/details/119352884

for true { select { case <-time.After(time.Minute * 3): // do something default: time.Sleep(time.Duration(1) * time.Second) } }

1.2 time.NewTicker-Ressourcen werden nicht rechtzeitig freigegebenbei Verwendung von time.NewTicker Sie müssen die Stop()-Methode manuell aufrufen, um Ressourcen freizugeben, andernfalls kommt es zu einem dauerhaften Speicherverlust

2 AuswahlblockierungBei Verwendung Wählen Sie, wenn es einen Fall gibt, der nicht vollständig abgedeckt ist und es keinen Standardzweig für die Verarbeitung gibt. Dies führt schließlich zu Speicherverlusten.

2.1 Goroutine-Blockierung verursachen und Speicherlecks verursachen

timer := time.NewTicker(time.Duration(2) * time.Second) defer timer.Stop() for true { select { case <-timer.C: // do something default: time.Sleep(time.Duration(1) * time.Second) } }

Oben Sobald die for-Schleifenbedingung den Standardwert erreicht, wird die Schleife inaktiv und führt schließlich dazu, dass die CPU in die Höhe schnellen kann3Die Kanalblockierung wird hauptsächlich in zwei Situationen unterteilt: Schreibblockierung und LeseblockierungDer gepufferte Kanal ist blockiert, weil der Puffer voll ist und der Schreibvorgang blockiert ist 4. Speicherverlust durch Goroutine 4.1 Anwenden von zu vielen Goroutinen

4.2 Goroutine-Blockierung

4.2.1 E/A-Problem

4.2.2 Die Mutex-Sperre wird nicht freigegeben

• Goroutine kann die Sperrressource nicht erhalten, wodurch die Goroutine blockiert wird

timer := time.NewTicker(time.Duration(2) * time.Second) // defer timer.Stop() for true { select { case <-timer.C: // do something default: time.Sleep(time.Duration(1) * time.Second) } }

Nach dem Login kopieren

4.2.3 Deadlock

Wenn zwei Slices gemeinsame Adressen haben, von denen eine eine globale Variable ist, kann die andere nicht GC sein.
Es wurde nach dem Anhängen des Slice verwendet und nicht bereinigt.

func main() { ch1 := make(chan int) ch2 := make(chan int) ch3 := make(chan int) go Getdata("https://www.baidu.com",ch1) go Getdata("https://www.baidu.com",ch2) go Getdata("https://www.baidu.com",ch3) select{ case v:=<- ch1: fmt.Println(v) case v:=<- ch2: fmt.Println(v) } }

Da Arrays der grundlegende Datentyp von Golang sind, belegt jedes Array einen anderen Speicherplatz und der Lebenszyklus stört sich nicht gegenseitig Wenn die Funktion von mehreren Goroutinen aufgerufen wird und das Array zu groß ist, führt dies zu einem Anstieg der Speichernutzung.

func main() { fmt.Println("main start") msgList := make(chan int, 100) go func() { for { select { case <-msgList: default: } } }() c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt, os.Kill) s := <-c fmt.Println("main exit.get signal:", s) }

Nach dem Login kopieren

Daher werden Slices oder Zeiger normalerweise zum Übertragen großer Arrays in Szenarios mit formalen Parametern verwendet, um kurzfristige Speicherauslastungsspitzen zu vermeiden.

[Verwandte Empfehlungen:Video-Tutorial ansehen,

Programmierunterricht

]

Das obige ist der detaillierte Inhalt vonWas sind die Ursachen für Golang-Speicherlecks?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!