Heim  >  Artikel  >  Backend-Entwicklung  >  Hat Golang GC?

Hat Golang GC?

(*-*)浩
(*-*)浩Original
2019-12-31 11:24:472975Durchsuche

Hat Golang GC?

GOs Garbage Collector

Go-Sprachgarbage Collection verwendet im Allgemeinen den klassischen Mark-and-Sweep-Algorithmus. (Empfohlenes Lernen: GO )

Vor Version 1.3 war der Garbage-Collection-Algorithmus von Golang sehr einfach, und dann wurde seine Leistung auch vielfach kritisiert: Go Runtime ist unter bestimmten Bedingungen (Speicher). (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher (Speicher) Bei Überschreitung des Schwellenwerts oder in regelmäßigen Abständen (z. B. 2 Minuten) erfolgt die Ausführung aller Aufgaben angehalten, der Mark&Sweep-Vorgang wird ausgeführt und die Ausführung aller Aufgaben wird nach Abschluss des Vorgangs gestartet.

In Szenarien, in denen viel Speicher verwendet wird, tritt beim Go-Programm bei der Speicherbereinigung ein sehr offensichtliches hängengebliebenes Phänomen (Stop The World) auf. Bei Hintergrunddienstprozessen, die eine hohe Reaktionsgeschwindigkeit erfordern, ist eine solche Verzögerung einfach nicht tolerierbar! Während dieser Zeit waren viele Teams im In- und Ausland, die die Go-Sprache in Produktionsumgebungen praktizierten, mehr oder weniger auf die Fallstricke von GC gestoßen.

Die damals übliche Methode zur Lösung dieses Problems bestand darin, die Menge des automatisch zugewiesenen Speichers so schnell wie möglich zu steuern, um die GC-Last zu reduzieren, und gleichzeitig die manuelle Speicherverwaltung zu verwenden, um mit Szenarien umzugehen erfordern große Speichermengen und eine hohe Frequenzzuweisung.

Ab Version 1.3 begann das Go-Team, die GC-Leistung kontinuierlich zu verbessern und zu optimieren. Mit jeder neuen Version von Go stehen die GC-Verbesserungen im Mittelpunkt aller Aufmerksamkeit.

In Version 1.3 trennt die Go-Laufzeit Markierungs- und Sweep-Vorgänge. Nach Abschluss der Markierung werden alle Tasks angehalten und die Sweep-Aufgaben werden ausgeführt parallel zu anderen Aufgaben wie gewöhnlichen Coroutine-Aufgaben ausgeführt.

Bei Ausführung auf einem Mehrkernprozessor versucht go, die GC-Aufgabe auf einem separaten Kern auszuführen, ohne die Ausführung des Geschäftscodes zu beeinträchtigen. Nach eigener Aussage des Go-Teams wurde die Pausenzeit um 50–70 % verkürzt.

Version 1.4 (die neueste stabile Version) weist nicht viele Leistungsänderungen an gc auf. In Version 1.4 hat ein Großteil des Laufzeitcodes die native C-Sprachimplementierung durch die Go-Sprachimplementierung ersetzt. Eine wesentliche Änderung bei gc besteht darin, dass es eine genaue GC erreichen kann.

Die C-Sprachimplementierung kann die Objektinformationen des Speichers während der GC nicht abrufen, sodass sie nicht genau zwischen gewöhnlichen Variablen und Zeigern unterscheiden kann. Sie kann gewöhnliche Variablen nur dann als Zeiger behandeln, wenn sich zufällig andere Objekte im Speicher befinden Leerzeichen, auf das diese gewöhnliche Variable zeigt, dann wird dieses Objekt nicht recycelt.

Die Go-Sprachimplementierung kennt die Typinformationen des Objekts vollständig und durchläuft beim Markieren nur das Objekt, auf das der Zeiger zeigt, wodurch die Verschwendung von Heap-Speicher in der C-Implementierung vermieden wird (ca. 10–30 % lösen) ).

In Version 1.5 hat das Go-Team wesentliche Verbesserungen an GC vorgenommen (Voraussichten wurden in 1.4 gelegt, beispielsweise die Einführung einer Schreibbarriere. Das offizielle Hauptziel besteht darin, Verzögerungen zu reduzieren).

Der Garbage Collector, der in go 1.5 implementiert wird, ist ein „nicht-generationeller, sich nicht bewegender, gleichzeitiger, dreifarbiger Mark-and-Sweep-Garbage Collector“.

Der Generationsalgorithmus wurde oben erwähnt und ist eine bessere Strategie zur Speicherbereinigung. Er ist jedoch meiner Meinung nach nicht allzu groß Go-Beamte erklärten außerdem, dass sie bei der GC-Optimierung von Version 1.6 berücksichtigt werden.

Gleichzeitig wird die oben vorgestellte dreifarbige Markierungsmethode eingeführt. Der Markierungsvorgang dieser Methode kann schrittweise ausgeführt werden, ohne jedes Mal den gesamten Speicherplatz zu scannen, was die Zeit zum Stoppen der Welt verkürzen kann .

Daraus ist ersichtlich, dass sich die Garbage-Collection-Leistung von Go bis zur Version 1.5 verbessert hat, aber für relativ ausgereifte Garbage-Collection-Systeme (wie Java JVM und Javascript V8) muss Go die optimieren Der Weg wird noch lange auf sich warten lassen (aber ich glaube, dass die Zukunft rosig sein wird~).

Das obige ist der detaillierte Inhalt vonHat Golang GC?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn