Discussion :

[fred_68]

Bonjour,

j'ai une question technique: lors de l'instanciation d'un objet, l'objet est créé, la référence contient ses attributs propres et méthodes propres. Mais qu'en est-il des méthodes héritées ?( et déclarées dans classe abstraite?) vont-elles aussi grossir s'inscrire à l'intérieur ou alors y a-t-il une référence vers la classe mère ? (Dans javascript par exemple la méthode prototype permet de ne pas stocker les méthodes dans l'espace mémoire de l'objet, on gagne ainsi de la place mémoire)
Y a-t-il quelque chose d'équivalent dans java ?

merci pour vos réponse.

(et bon confinement)

[thelvin]

Hello,

lors de l'instanciation d'un objet, l'objet est créé, la référence contient ses attributs propres

Oui

et méthodes propres.

Non. Les méthodes sont les mêmes pour toutes les instances de cette classe. On va pas s'amuser à en faire des copies à chaque instance. Elles sont avec la classe, et zou.

[Badshade23]

Bonjour,

Non. Les méthodes sont les mêmes pour toutes les instances de cette classe. On va pas s'amuser à en faire des copies à chaque instance. Elles sont avec la classe, et zou.

Donc, on a en mémoire un endroit la classe est définie et où on à uniquement les méthodes et le contenu static ?
Quant à l'héritage comme le demande fred_68 notre classe en mémoire à un pointeur sur la classe mère donc ? Pour éviter tout type de redondance (sauf pour les @override bien sûr ^^) ?

[thelvin]

Hello,

Donc, on a en mémoire un endroit la classe est définie et où on à uniquement les méthodes et le contenu static ?

Grosso-merdo.

Mais, la définition de la classe (méthodes et champs qui existent) et la valeur des champs static, ne sont pas au même endroit. L'un est du domaine de l'exécutable et du schéma en lecture seule, l'autre est une donnée vivante en lecture-écriture (même si le langage définit des champs "final", il faut bien les initialiser d'une manière ou d'une autre, et pour raisons pragmatiques, Java a défini ça avec toujours de l'exécution dynamique qui calcule la valeur. Par conséquent le champ existe au moins toujours avec la valeur par défaut au nettoyage de la mémoire, et la valeur calculée qu'il gardera.)

Quant à l'héritage comme le demande fred_68 notre classe en mémoire à un pointeur sur la classe mère donc ? Pour éviter tout type de redondance (sauf pour les @override bien sûr ^^) ?

Oui, mais en réalité la JVM fait ce qu'elle veut. Il n'est pas rare de copier les définitions de méthodes si ça évite d'aller les chercher. Il n'est pas rare de les insérer inline dans les parties de code qui appellent ces méthodes.

Il faut comprendre que la JVM fait ce qu'il y a de mieux à faire, du moment qu'elle fait ce que le programme Java est censé faire tel que programmé. Comment les choses sont organisées en mémoire quand le langage ne croit pas nécessaire de le définir, n'est pas le problème du programmeur. C'est le problème de la JVM.

[Badshade23]

Il faut comprendre que la JVM fait ce qu'il y a de mieux à faire, du moment qu'elle fait ce que le programme Java est censé faire tel que programmé. Comment les choses sont organisées en mémoire quand le langage ne croit pas nécessaire de le définir, n'est pas le problème du programmeur. C'est le problème de la JVM.

Oui c'est sûr mais des fois quant on a des restrictions de performance c'est toujours utile de savoir comme java gère la mémoire. Car pour des programmes qui génèrent des milliards de valeurs et qui tournent pendant 24h on peut vite être dépassé par la gestion de la mémoire.
Enfin merci pour ces détails

[thelvin]

Oui c'est sûr mais des fois quant on a des restrictions de performance c'est toujours utile de savoir comme java gère la mémoire.

Mais justement, pour ces questions-là on n'en sait rien. A la rigueur en cas de problème on peut utiliser les outils de diagnostic pour voir l'état de la mémoire.

Car pour des programmes qui génèrent des milliards de valeurs et qui tournent pendant 24h on peut vite être dépassé par la gestion de la mémoire.

C'est vrai, et d'ailleurs l'approche cavalière de Java de ne pas tout dire sur la manière dont c'est organisé (en grande partie parce que c'est organisé comme il décide que ça l'est quand il décide de faire comme ça) pose parfois des problèmes. Mais le plus souvent, c'est plutôt qu'on empêche Java de récupérer la mémoire, ou d'utiliser les optimisations de stockage en tableau, et le langage est parfaitement clair à ce sujet.

Toujours est-il que ces questions-là concernent les instances d'objets, pas les classes.

[tchize_]

Oui c'est sûr mais des fois quant on a des restrictions de performance c'est toujours utile de savoir comme java gère la mémoire. Car pour des programmes qui génèrent des milliards de valeurs et qui tournent pendant 24h on peut vite être dépassé par la gestion de la mémoire.
Enfin merci pour ces détails

Alors soit t'as des tonnes de données à garder en mémoire, dans ce cas là, le plus simple est de faire des mesure in situ sur comment ça se comporte. Tu lance l'appli 24h ou une semaine sur des données représentative et tu regarde comment se comporte ton appli.
Tu peux aussi essayer de te donner un idées des bornes. J'ai déjà du faire ça par le passé pour choisir entre plusieurs structures de Map dans un appli 24/7 qui pouvait garder en mémoire des dixaines de milliers d'entrées. Mon expérience est que EHCache est bien pratique pour ça, cette librairie possède des méthodes qui évaluent la consommation mémoire d'un arbre d'objet (ça lui sert à évaluer la taille de son cache ) et que tu peux utiliser en test pour regarder comment évolue une structure avec la charge et essayer quelques variation de code.

Soit ton programme fait tourner les données en continu (création, manipulation, destruction). Et là, la question de la taille des objets n'a pas vraiment d'importance directe, ce qui est important c'est de bien laisser le GC faire son boulot en évitant de garder des références dans tous les sens. C'est sur que si tu traite 1000 données à un instant T et que chaque instance occupe 1M de mémoire, tu n'aura pas la même empreinte en mémoire que si tes instances occupent chacune 200bytes . Une chose est relativement sûre, si tu ne génère pas du code à la volée, l'empreinte mémoire d'une grande quantité d'instance sera principalement conditionnée par la taille des champs dans l'instance, pas à l'objet lui même.

Dans tous les cas, évite ce qu'on appelle l'optimisation précoce qui consiste a essayer d'optimiser ton code (ici en terme de mémoire) avant même d'avoir fait des mesures. Ca aboutit en général à de fausses idée, voir des superstitions, ... Je dis pas qu'il faut y aller comme un goret avec la mémoire, mais architecture ton code proprement, lance le, fait des mesures et puis seulement, en fonction du retour des mesure, détermine ce qui pourrait nécessiter une optimisation