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)
}
}
Nach dem Login kopieren
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
2.2 Schleifenleerlauf verursacht CPU-Anstieg
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
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 kann3 Die Kanalblockierung wird hauptsächlich in zwei Situationen unterteilt: Schreibblockierung und Leseblockierung Der 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
Die E/A-Verbindung legt kein Timeout fest, was dazu führt, dass die Goroutine weiter wartet und der Code weiterhin blockiert.
4.2.2 Die Mutex-Sperre wird nicht freigegeben
Wenn das Programm blockiert, werden andere Goroutinen blockiert Blockieren Sie auch von Slice
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)
}
}
Nach dem Login kopieren
6. Wertübertragung von Arrays
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!