Ist das Poolen von Objekten eine veraltete Technik?

Ich bin mit dem Konzept des Objekt-Poolings sehr vertraut und versuche es immer so oft wie möglich anzuwenden.

Außerdem dachte ich immer, dass Objekt-Pooling die Standardnorm ist, da ich beobachtet habe, dass Java selbst sowie die anderen Frameworks so viel wie möglich Pooling verwenden.

Kürzlich habe ich jedoch etwas gelesen, das für mich völlig neu (und nicht intuitiv?) War.

Dieses Pooling führt zu einer Verschlechterung der Programmleistung, insbesondere bei gleichzeitigen Anwendungen, und es ist ratsam, newstattdessen Objekte zu instanziieren , da die Instanziierung eines Objekts in neueren JVMs sehr schnell ist.

Ich habe das im Buch gelesen: Java Concurrency in Practice

Jetzt beginne ich zu überlegen, ob ich hier etwas missverstehe, da im ersten Teil des Buches empfohlen wurde, Executorsdiese Wiederverwendung zu verwenden , Threadanstatt neue Instanzen zu erstellen.

Ist das Pooling von Objekten heutzutage veraltet?

Es wird als allgemeine Technik abgelehnt, da - wie Sie bemerkt haben - die Erstellung und Zerstörung von kurzlebigen Objekten per se (dh Speicherzuweisung und GC) in modernen JVMs äußerst kostengünstig ist. Die Verwendung eines handgeschriebenen Objektpools für Ihre Standardobjekte ist daher wahrscheinlich langsamer, komplizierter und fehleranfälliger als normal new. *

Es hat jedoch immer noch seine Verwendung für spezielle Objekte, deren Erstellung relativ kostspielig ist, wie DB- / Netzwerkverbindungen, Threads usw.

* _{Einmal musste ich die Leistung einer durchsuchenden Java-App verbessern. Die Untersuchung ergab, dass versucht wurde, mithilfe eines Objektpools Millionen von Objekten zuzuweisen ... und der clevere Typ, der ihn geschrieben hat, verwendete eine einzige globale Sperre, um ihn threadsicher zu machen. Durch das Ersetzen des Pools durch plain newwurde die App 30-mal schneller.}

Die Antwort auf die konkrete Frage: "Ist Objekt-Pooling eine veraltete Technik?" ist:

Objekt-Pooling wird häufig an bestimmten Stellen verwendet - Thread-Pooling, Datenbankverbindungs-Pooling usw.

Die allgemeine Objekterstellung war noch nie ein langsamer Prozess. Das Pooling an sich verbraucht Ressourcen - Speicher und Rechenleistung. Jede Optimierung ist ein Kompromiss.

Die Regel ist:

Vorzeitige Optimierung ist böse !!!

Aber wann ist eine bestimmte Optimierung verfrüht?

Vorzeitige Optimierung ist jede Optimierung, die durchgeführt wird, bevor Sie einen Engpass durch gründliche Profilerstellung aufgedeckt haben .

In Situationen, in denen Sie die Garbage Collection vollständig vermeiden möchten, halte ich das Objekt-Pooling für die einzig gangbare Alternative. Also nein, es ist absolut keine veraltete Technik.

Messen

Es hängt ganz von Ihrem Anwendungsfall, der Größe Ihrer Objekte, Ihrer JVM, Ihren JVM-Optionen, dem von Ihnen aktivierten GC und einer Reihe anderer Faktoren ab.

Kurz gesagt: Messen Sie es vorher und messen Sie es nachher. Angenommen, Sie verwenden ein Object Pooling Framework (wie von Apache), dann sollte es nicht zu schmerzhaft sein, zwischen Implementierungen zu wechseln.

Zusätzlicher Leistungstest-Tipp: Lassen Sie die JVM zuerst etwas aufwärmen und führen Sie die Tests mehrmals auf einer laufenden JVM aus. Sie kann sich auch anders verhalten.

Dieses Pooling führt zu einer Verschlechterung der Programmleistung, insbesondere bei gleichzeitigen Anwendungen, und es ist ratsam, stattdessen neue Objekte zu instanziieren, da die Instanziierung eines Objekts in neueren JVMs sehr schnell ist.

Kommt auf den Kontext an.

Ich weiß nicht, ob es hier einen sich ändernden Trend gibt, aber es wird sicherlich der Fall sein, dass es davon abhängt . Wenn Ihre Java-Klasse eine externe Ressource verwaltet, z. B. eine RMI-Verbindung oder das Laden einer Ressourcendatei usw., können die Kosten für die Objektinstanziierung dennoch hoch sein (obwohl diese Ressourcen möglicherweise bereits für Sie zusammengefasst wurden!). Als allgemeine Praxis würde ich dem Buch zustimmen.