Votre collègue n'a aucune idée de ce dont ils parlent.
Votre opération la plus chère serait de les écouter . Ils vous ont fait perdre votre temps à vous orienter vers des informations obsolètes depuis plus de dix ans (à la date à laquelle cette réponse a été publiée) et à passer du temps à poster ici et à rechercher Internet sur la vérité.
Espérons qu'ils ne font que régurgiter par ignorance quelque chose qu'ils ont entendu ou lu il y a plus de dix ans et qu'ils ne savent pas mieux. Je prendrais également pour suspect tout ce qu'ils ont dit, il devrait s'agir d'une erreur bien connue de quiconque se tient au courant de toute façon.
Tout est un objet (sauf primitives
)
Tous les int, long, double
objets autres que les primitives ( , etc.) sont des objets en Java. Il n'y a aucun moyen d'éviter la création d'objets en Java.
La création d'objets en Java, en raison de ses stratégies d'allocation de mémoire, est plus rapide que le C ++ et, à toutes fins pratiques, par rapport à tout le reste de la machine virtuelle Java, elle peut être considérée comme "libre" .
Au début, comme à la fin des années 1990 et au début des années 2000, l’implémentation réelle d’objets a été légèrement ralentie par l’implémentation de JVM. Cela n’a pas été le cas depuis au moins 2005.
Si vous accordez la prise -Xms
en charge de toute la mémoire dont vous avez besoin pour que votre application fonctionne correctement, il se peut que le GC ne soit jamais obligé d'exécuter et de balayer la plupart des déchets dans les implémentations modernes du GC. Les programmes de courte durée peuvent ne jamais supporter la GC.
Il n'essaie pas d'optimiser l'espace libre, ce qui est un casse-tête de toute façon, il optimise les performances de l'exécution. Si cela signifie que la pile JVM est allouée presque à 100% tout le temps, qu’il en soit ainsi. De toute façon, la mémoire de pile JVM libre ne vous fournit rien.
Il y a une idée fausse que le GC va libérer la mémoire de manière utile au reste du système, c'est complètement faux!
Le segment de mémoire de la machine virtuelle Java ne grossit pas et ne diminue pas, de sorte que le reste du système est affecté positivement par la mémoire disponible dans le segment de mémoire de la machine virtuelle Java . -Xms
alloue TOUT ce qui est spécifié au démarrage et sa méthode heuristique consiste à ne jamais réellement restituer cette mémoire au système d'exploitation afin de la partager avec tout autre processus du système d'exploitation jusqu'à la fermeture complète de cette instance de la machine virtuelle Java. -Xms=1GB -Xmx=1GB
alloue 1 Go de RAM quel que soit le nombre d'objets créés à un moment donné. Certains paramètres permettent de libérer des pourcentages de la mémoire de tas, mais pour des raisons pratiques, la JVM n'est jamais en mesure de libérer suffisamment de mémoire pour que cela se produise.ainsi, aucun autre processus ne peut récupérer cette mémoire, de sorte que le reste du système ne bénéficie pas non plus de la pile JVM. Un RFE pour cela a été "accepté" le 29-NOV-2006, mais rien n’a été fait à ce sujet. Ce comportement n’est considéré comme une préoccupation par personne d’autorité.
Il existe une idée fausse selon laquelle la création de nombreux objets de courte durée entraîne la pause de la machine virtuelle Java pendant de longues périodes. Cette erreur est également fausse.
Les algorithmes actuels du GC sont en fait optimisés pour la création de nombreux petits objets de courte durée. Il s’agit en fait de l’heuristique à 99% pour les objets Java dans chaque programme. Les tentatives de regroupement d’objets vont en réalité ralentir les performances de la machine virtuelle Java dans la plupart des cas.
Les seuls objets qui ont besoin d'être mis en pool aujourd'hui sont les objets qui font référence à des ressources finies externes à la machine virtuelle Java; Les sockets, fichiers, connexions à la base de données, etc. peuvent être réutilisés. Les objets normaux ne peuvent pas être regroupés dans le même sens que dans les langues vous permettant d'accéder directement aux emplacements de mémoire. La mise en cache des objets est un concept différent et peut être ou ne pas être ce que certaines personnes appellent naïvement le pooling . Les deux concepts ne sont pas la même chose et ne doivent pas être confondus.
Les algorithmes GC modernes ne rencontrent pas ce problème car ils ne désallouent pas de manière planifiée, ils le font quand la mémoire disponible est nécessaire pour une génération donnée. Si le tas est suffisamment grand, aucune désallocation ne se produit suffisamment longtemps pour provoquer des pauses.
Les langages dynamiques orientés objet battent le C même aujourd'hui plusieurs jours sur les tests sensibles au calcul.