Où vivent les méthodes? Stack ou en tas?

Question

Je sais que les variables locales et les paramètres des méthodes résident en pile, mais je ne suis pas en mesure de savoir où vivent réellement les méthodes dans le cas de Java?

Si je déclare un objet Thread tel que:

Thread t=new Thread();
t.start();

Cela signifie donc que j'ai créé un appel séparé de méthodes en dehors de la méthode principale. Qu'est-ce que ça veut dire? Est-ce que cela signifie l’appel de séquences de méthodes séparées sur la mémoire de pile? Ai-je raison?

Answer 1

Chaque thread se voit attribuer sa propre pile.

Cet article a une bonne introduction à la séparation de mémoire dans un processus Java.

  

À l'intérieur de la machine virtuelle Java, chaque   le fil est attribué une pile Java, qui   contient des données, aucun autre thread ne peut   accès, y compris les variables locales,   paramètres et les valeurs de retour de chaque   méthode que le thread a invoqué. le   les données sur la pile sont limitées à   types primitifs et références d'objet.   Dans la JVM, il n’est pas possible de   placer l'image d'un objet réel sur   la pile. Tous les objets résident sur le   tas.

J'ai vu de nombreux scénarios dans lesquels les clients ont implémenté des serveurs extrêmement threadés sur la base du principe que chaque thread fait très peu, et qu'ils rencontrent des problèmes de mémoire. C'est parce que chaque thread se voit attribuer sa propre pile, et cela (évidemment) s'additionne. Je pense que la valeur par défaut est 512k par thread, mais je n'ai pas trouvé de source canonique pour cela.

Answer 2

Si je me souviens bien, le code de la méthode vivra lui-même dans la partie code de la mémoire, alors que les variables déclarées en interne habiteront dans la pile et que les objets seront créés sur le tas. En Java, les pointeurs et les primitives de variables résident dans la pile, tandis que les objets créés se trouvent dans le tas.

Pour une (mauvaise) représentation ASCII:

-------
|STACK|
-------
|FREE |
-------
|HEAP |
-------
|CODE |
-------

Où STACK représente la pile, FREE représente la mémoire disponible, HEAP représente le tas et CODE représente l’espace de code.

C’est ce que ma mémoire dit: certains détails peuvent être faux.

Answer 3

La pile est composée d'invocations de méthodes. Ce que java pousse sur la pile, c'est un enregistrement d'appel de méthode, qui encapsule toutes les variables (paramètres et variables instanciées localement) pour cette méthode. Lorsque vous démarrez une application Java, la méthode principale (qui inclut automatiquement le paramètre args) est la seule chose sur la pile:

main(args)

Quand vous dites que vous créez un objet Foo et appelez foo.method (), la pile ressemble maintenant à:

method()
main(args)

Lorsque les méthodes sont appelées, elles sont placées dans la pile et à leur retour, elles sont supprimées ou "sautées". de la pile. Au fur et à mesure que les variables sont déclarées et utilisées, l’entrée de la pile, qui correspond à la méthode actuelle (située en haut de la pile), s’agrandit pour inclure la taille de la variable.

Pour votre exemple avec des threads, chaque thread aura sa propre pile qui existe indépendamment de la pile de chaque thread.

Answer 4

La pile contient toutes les variables locales et tous les invocations de méthodes actives. Le tas contient tout le reste.

En ce qui concerne votre question secondaire: cela signifie qu'une nouvelle pile est créée avec sa propre mémoire dédiée. Alors que votre nouveau thread partagera l’espace total de mémoire (mémoire) alloué par jvm

Answer 5

Le segment de mémoire est divisé en plusieurs générations.

Le bytecode, et son code machine compilé par JIT, se trouve dans la génération permanente, avec des chaînes internes et d'autres données de classe.

Même s’il s’appelle le "permanent" génération, il peut encore être ramassé des ordures. Certaines bibliothèques, certains frameworks et certains langages JVM génèrent du bytecode au moment de l'exécution. La génération permanente doit donc parfois être nettoyée. Tout comme les autres générations du tas, mais (on espère généralement) moins fréquemment.

Answer 6

Le code secondaire et / ou le code JIT réel demeurerait dans la mémoire du processus. Il n’y aura probablement qu’une copie dans la mémoire de processus, car tous les threads d’un processus partagent cette mémoire. Toutes les variables partagées par ces threads seront accessibles par les méthodes communes. Les variables locales aux threads (même les variables locales de méthode utilisées dans un thread) seront créées dans la mémoire de ce thread.