La mise en commun d'objets est-elle une technique obsolète?

Je connais très bien le concept de pooling d’objets et j’essaie toujours de l’utiliser le plus possible.

De plus, j’ai toujours pensé que le pool d’objets était la norme, car j’ai observé que Java lui-même, ainsi que les autres frameworks, utilisait le pooling autant que possible.

Récemment, j’ai lu quelque chose de complètement nouveau (et contre-intuitif?) Pour moi.

Ce regroupement nuit en fait aux performances des programmes, en particulier dans les applications concurrentes, et il est conseillé d’instancier les newobjets, car dans les machines JVM plus récentes, l’instanciation d’un objet est très rapide.

Je lis ceci dans le livre: Java Concurrency in Practice

Maintenant, je commence à penser que si je ne comprends pas bien quelque chose ici, car la première partie du livre recommandait d’utiliser Executorscette méthode de réutilisation Threadau lieu de créer de nouvelles instances.

Alors, le pool d'objets est-il devenu obsolète de nos jours?

Elle est déconseillée en tant que technique générale car, comme vous l'avez remarqué, la création et la destruction d'objets de courte durée (c.-à-d. L'allocation de mémoire et la GC) sont extrêmement économiques dans les machines virtuelles modernes. Il est donc probable que l'utilisation d'un pool d'objets écrit à la main pour vos objets usuels soit plus lente, plus compliquée et plus sujette aux erreurs qu'une erreur ordinaire new. *

Cependant, il a encore des utilisations pour des objets spéciaux dont la création est relativement onéreuse, comme les connexions DB / réseau, les threads, etc.

* _{Une fois, j'ai dû améliorer les performances d'une application Java d'analyse. L'enquête a révélé une tentative d'utilisation d'un pool d'objets pour allouer des millions d'objets ... et l'intelligent type qui l'a écrit a utilisé un verrou global unique pour le rendre thread-safe. Remplacer la piscine par uni a newrendu l'application 30 fois plus rapide.}

La réponse à la question concrète: "La mise en commun d'objets est-elle une technique obsolète?" est:

Le regroupement d'objets est largement utilisé dans des lieux spécifiques - regroupement de threads, regroupement de connexions de bases de données, etc.

La création générale d'objets n'a jamais été un processus lent. Le regroupement en soi consomme des ressources - mémoire et puissance de traitement. Toute optimisation est un compromis.

La règle est la suivante:

L'optimisation prématurée est mauvaise !!!

Mais quand une optimisation donnée est-elle prématurée?

Une optimisation prématurée est une optimisation effectuée avant d'avoir découvert un goulot d'étranglement via un profilage approfondi .

Dans les situations où vous souhaitez éviter complètement le ramassage des ordures, je pense que le regroupement d'objets est la seule alternative viable. Donc non, ce n'est absolument pas une technique obsolète.

Mesure

Cela dépend complètement de votre cas d'utilisation, de la taille de vos objets, de votre machine virtuelle Java, de vos options de machine virtuelle, de ce que vous avez activé dans le GC et d'une foule d'autres facteurs.

En bref: mesurez-le avant et mesurez-le après. En supposant que vous utilisiez un framework de pool d’objets (comme celui d’Apache), il ne devrait pas être trop pénible d’échanger les implémentations.

Conseil de test de performance supplémentaire - laissez la JVM se réchauffer un peu, exécutez les tests plusieurs fois sur une JVM en cours d’exécution, elle peut se comporter différemment.

Ce regroupement nuit en fait aux performances des programmes, en particulier dans les applications concurrentes, et il est conseillé d'instancier de nouveaux objets, car dans les nouvelles machines virtuelles, l'instanciation d'un objet est très rapide.

Dépend du contexte.

Je ne sais pas s'il y a une tendance changeante ici, mais ça va certainement être le cas, ça dépend . Si votre classe Java gère une ressource externe, telle qu'une connexion RMI ou le chargement d'un fichier de ressources, etc., le coût de l'instanciation d'objet peut toujours être élevé (même si ces ressources peuvent déjà être mises en pool pour vous!). En règle générale, je suis d'accord avec le livre.