it-swarm-eu.dev

Ist Objektpooling eine veraltete Technik?

Ich bin mit dem Konzept des Objektpoolings sehr vertraut und versuche immer, es so oft wie möglich zu verwenden.

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

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

Dieses Pooling verschlechtert tatsächlich die Programmleistung, insbesondere in gleichzeitigen Anwendungen, und es ist ratsam, stattdessen new -Objekte zu instanziieren, da in neueren JVMs die Instanziierung eines Objekts sehr schnell ist.

Ich habe das im Buch gelesen: Java Concurrency in Practice

Jetzt fange ich an zu überlegen, ob ich hier etwas missverstehe, da im ersten Teil des Buches empfohlen wurde, Executors zu verwenden, die Threads wiederverwenden, anstatt neue Instanzen zu erstellen.

Ist das Pooling von Objekten heutzutage veraltet?

62
user10326

Es ist als allgemeine Technik veraltet, da - wie Sie bemerkt haben - die Erstellung und Zerstörung kurzlebiger Objekte an sich (d. H. Speicherzuweisung und GC) in modernen JVMs äußerst billig ist. Die Verwendung eines handgeschriebenen Objektpools für Ihre normalen Objekte ist daher höchstwahrscheinlich langsamer, komplizierter und fehleranfälliger als einfaches 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 Crawler-App verbessern Java App. Die Untersuchung ergab, dass versucht wurde, mithilfe eines Objektpools Millionen von Objekten zuzuweisen ... und der clevere Typ, der sie geschrieben hat, verwendete eine einzige globale Sperren, um den Thread sicher zu machen. Durch Ersetzen des Pools durch einfaches new wurde die App 30-mal schneller.

72
Péter Török

Die Antwort auf die konkrete Frage: "Ist das Zusammenlegen von Objekten eine veraltete Technik?" ist:

Nein. Objektpooling wird häufig an bestimmten Stellen verwendet - Thread-Pooling, Datenbankverbindungspooling usw.

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

Die Regel lautet:

Vorzeitige Optimierung ist böse !!!

Aber wann ist eine bestimmte Optimierung verfrüht?

Vorzeitige Optimierung ist jede Optimierung durchgeführt, bevor Sie Aufdeckung eines Engpasses über gründliche Profilerstellung durchgeführt haben.

36
Boris Yankov

In Situationen, in denen Sie die Speicherbereinigung vollständig vermeiden möchten, ist Objektpooling meiner Meinung nach die einzig praktikable Alternative. Also nein, es ist absolut keine veraltete Technik.

9
Jer

Dieses Pooling verschlechtert tatsächlich die Programmleistung, insbesondere in gleichzeitigen Anwendungen, und es ist ratsam, stattdessen neue Objekte zu instanziieren, da in neueren JVMs die Instanziierung eines Objekts sehr schnell ist.

Kommt auf den Kontext an.

8
user204677

Messen

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

Kurzum: Messen Sie es vorher und messen Sie es danach. Angenommen, Sie verwenden ein Objektpooling-Framework (wie von Apache), sollte es nicht zu schmerzhaft sein, zwischen Implementierungen zu wechseln.

Zusätzlicher Tipp für Leistungstests: Lassen Sie die JVM zuerst etwas aufwärmen, führen Sie die Tests mehrmals auf einer laufenden JVM aus. Sie kann sich anders verhalten.

8
Martijn Verburg

Ich weiß nicht, ob sich hier ein Trend ändert, aber es wird sicherlich so sein, dass es kommt darauf an. 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 sicherlich immer noch hoch sein (obwohl diese Ressourcen möglicherweise zusammengefasst werden) Sie schon!). Als allgemeine Praxis würde ich dem Buch zustimmen.

5
Jeremy