L'oggetto sta raggruppando una tecnica deprecata?

È deprecato come tecnica generale, perché - come hai notato - la creazione e la distruzione di oggetti a vita breve di per sé (ad esempio l'allocazione di memoria e GC) è estremamente economica nelle moderne JVM. Quindi utilizzare un pool di oggetti scritti a mano per gli oggetti run-of-the-mill è molto più lento, più complicato e più soggetto a errori rispetto a new . *

Tuttavia ha ancora i suoi usi, per oggetti speciali la cui creazione è relativamente costosa, come DB / connessioni di rete, thread ecc.

* _{Una volta ho dovuto migliorare le prestazioni di un'app Java in movimento. L'indagine ha scoperto un tentativo di utilizzare un pool di oggetti per allocare milioni di oggetti ... e il ragazzo intelligente che l'ha scritto ha utilizzato un unico lucchetto globale per renderlo sicuro. La sostituzione del pool con new ha reso l'app 30 volte più veloce.}

La risposta alla domanda concreta: 'L'oggetto raggruppa una tecnica deprecata?' è:

No. Il pooling di oggetti è ampiamente utilizzato in luoghi specifici: pool di thread, pool di connessioni database ecc.

La creazione di oggetti generali non è mai stata un processo lento. Il raggruppamento di per sé consuma risorse - memoria e potenza di elaborazione. Qualsiasi ottimizzazione è un compromesso.

La regola è:

L'ottimizzazione prematura è cattiva !!!

Ma quando è prematura una data ottimizzazione?

L'ottimizzazione prematura è qualsiasi ottimizzazione eseguita prima che abbia scoperto un collo di bottiglia tramite un profilo completo .

Nelle situazioni in cui si desidera evitare completamente la garbage collection, penso che il pooling degli oggetti sia l'unica alternativa valida. Quindi no, non è assolutamente una tecnica deprecata.

That pooling actually makes program performance worse especially in concurrent applications, and it is advisable to instantiate new objects instead, since in newer JVMs, instantiation of an object is really fast.

Dipende dal contesto.

Misura

Dipende completamente dal tuo caso d'uso, dalle dimensioni dei tuoi oggetti, dalla tua JVM, dalle tue opzioni JVM, dal tipo di GC che hai attivato e da tutta una serie di altri fattori.

In breve: misuralo prima e misuralo dopo. Supponendo che tu stia utilizzando un framework di pool di oggetti (come da Apache), non dovrebbe essere troppo doloroso scambiare le implementazioni.

Suggerimento per i test delle prestazioni extra: lascia che la JVM si scaldi un po 'prima, esegui i test su una JVM in esecuzione un numero di volte, può comportarsi in modo diverso.

Non so se c'è una tendenza al cambiamento qui, ma sarà certamente il caso che dipenda . Se la tua classe Java sta gestendo una risorsa esterna, come una connessione RMI o il caricamento di un file di risorse, ecc., Sicuramente i costi per l'istanziazione degli oggetti possono essere ancora elevati (anche se queste risorse potrebbero essere già disponibili per te!). Come pratica generale sarei d'accordo con il libro.