Wenn ein Objekt in Java keine Referenzen hat, wird es zu Müll. Wenn es nicht rechtzeitig recycelt und der Speicher freigegeben wird, sammelt sich der Müll immer mehr an und schließlich ist nicht mehr genügend Speicher vorhanden!, und die JVM wird aufhören zu laufen.
Manche Leute sind verwirrt: Normalerweise zerstören wir Objekte beim Codieren nicht explizit. Wie kann das Programm also gut laufen?
Hier geht es um den heutigen Protagonisten, den Daemon-Thread GC, der nach einem bestimmten Algorithmus von Zeit zu Zeit Müllobjekte freigibt und gleichzeitig die hohe Verfügbarkeit gewährleistet Speicher und halten den normalen Betrieb des Prozesses aufrecht.
Schauen wir uns den folgenden Code an:
public class DemoDatatype {
public static void main(String[] args) {
new DemoDatatype();
System.gc();
System.out.println("over!");
}
@Override
protected void finalize() throws Throwable {
System.out.println("Arbeit vor Garbage Collection!");
super.finalize() ;
}
}
Programmausgabe: vorbei!
Wir haben ein Objekt „new DemoDatatype()“ erstellt, weil Ohne Referenz wird es schnell zum Müllobjekt, aber wird es definitiv recycelt? Zumindest zeigen die obigen Ergebnisse, dass es kein Recycling gibt, da der JVM über genügend Speicher verfügt und ich mir nicht die Mühe mache, Sie zu recyceln. Ich bin sehr ressourcenintensiv.
Es gibt eine statische Methode gc() unter der Klasse java.lang.System. Durch aktiven Aufruf können Sie den GC benachrichtigen: Hey, ich habe hier Müll, kommen Sie und helfen Sie sammle es. Es kann jedoch sein, dass der GC nicht unbedingt sofort auf Ihre Anfrage reagiert. Auf halber Strecke kann es zu einem Stau kommen, und es ist nicht klar, wann er eintreffen wird. Führen Sie gc() aus, um die Ergebnisse anzuzeigen:
public class DemoDatatype {
public static void main(String[] args) {
new DemoDatatype ( );
System.gc();
System.out.println("over!");
}
@Override
protected void finalize() throws Throwable {
System.out.println("Arbeit vor Garbage Collection!");
super.finalize();
}
}
Programmausgabe: vorbei!
Arbeit vor der Müllabfuhr!
Oder: Arbeiten vor der Müllabfuhr!
GC funktionierte, weil es im Leerlauf war, also reagierte es rechtzeitig, wurde aber nicht sofort ausgeführt, zufällige Ereignisse. GC führt die finalize()-Methode vor der Garbage Collection aus. Wir wissen, dass GC die beantragten Objekte nur durch ungewöhnliche Mittel kennt. Die Funktion von finalize() besteht darin, einige Ressourcen vor der Speicherbereinigung freizugeben, z. B. einige Ressourcen, die von gc nicht recycelt werden können, z. B. „nicht neuer“ Speicher, nicht geschlossene E/A usw. Verlassen Sie sich jedoch nicht auf finalize(), um Ressourcen freizugeben. Der GC ist möglicherweise nicht erreichbar und kann zu Speicherverlusten führen. Unter welchen Umständen wird GC ausgelöst? 1) GC ist ein Daemon-Thread. Als Mitglied der Dienstleistungsbranche hat er die niedrigste Priorität und wird daher nur gestartet, wenn die Anwendung inaktiv ist. 2) Wenn der Speicher nicht ausreicht und die Anwendung kurz vor dem Tod steht, tritt der GC vor, um Müll zu beseitigen und Speicher freizugeben. Wenn der Speicherverlust schwerwiegend ist, stoppt die JVM. GC-Arbeit verbraucht auch Systemressourcen. Wie vermeidet man unnötigen Overhead? 1) Erstellen Sie keinen Müll: Reduzieren Sie die Verwendung temporärer Objekte, lassen Sie sie nach der Verwendung leer. 2) Fordern Sie GC nicht aktiv an: Rufen Sie system.gc nicht explizit auf ()
3) Klären Sie den Lebenszyklus von Objekten und zerstören Sie sie aktiv 4) Vermeiden Sie die konzentrierte Erstellung einer großen Anzahl nutzloser Objekte, z. B. das Spleißen einer großen Anzahl von Zeichenfolgen
5) Achten Sie während des Codierungsprozesses auf Speicherlecks, um sicherzustellen, dass der Code korrekt ist.
