Aujourd'hui, j'ai répondu à une question liée à StackoverflowException. La personne a demandé lorsque l'exception StackoverFlow se produit
Voir ce lien façons les plus simples Causer un débordement de pile en C #, C ++ et Java
Donc, ma question est qu'il y a une méthode par laquelle nous pouvons calculer la méthode des piles d'appel de méthode de manière dynamique dans notre programme, puis appliquer un chèque avant d'appeler une méthode qui vérifie si la pile d'appels de méthode a de l'espace pour l'adapter ou non StackoverflowException.
Comme je suis une personne Java, je cherche Java, mais aussi à la recherche d'une explication liée au concept sans limitation d'un langage de programmation.
5 Réponses :
Je pense que vous pouvez utiliser trace de pile code> pour obtenir la taille de la pile d'appel de méthode comme suit StackTraceElement[] stacktrace = Thread.currentThread().getStackTrace();
@Sumit Singh Une trace de pile est une sorte de vision des cadres de pile actifs à un moment donné pendant l'exécution d'un programme. Cela ne décrit pas sa taille.
Il n'y a pas d'informations sur la taille de la pile dans un StackTraceElement . -1
@ user207421but Le tableau a une longueur. -1
J'espère que je devine ce que vous demandez vraiment. Au début, je pensais que vous demandiez combien d'appels devaient profondément votre appel était sur le point d'être. En d'autres termes, je pensais que vous vouliez savoir à quelle place vous deviez déclencher cette exception, en fonction de vos circonstances actuelles. Ensuite, j'ai décidé que vous vouliez vraiment savoir combien de pile vous devez jouer. Dans ce cas, il existe une autre question de pile-overflow qui semble aborder cela, ici. Quelle est la profondeur maximale de la pile d'appels Java? < / a>
Cela vous indique comment définir cela comme paramètre de ligne de commande Java (à Java, pas votre programme).
De toute façon, j'aimerais souligner que le débordement de la pile m'est principalement arrivé lorsque j'avais une récursion sans fin. J'ai eu des méthodes écrites (par erreur, bien sûr) qui s'appelaient eux-mêmes et devaient s'arrêter quand le problème est résolu, mais d'une manière ou d'une autre, la condition de résiliation n'a jamais été atteinte. Cela met l'invocation de la méthode sur la pile de plus et encore jusqu'à ce que le maximum soit dépassé. Pas ce que j'avais en tête.
J'espère que cela aide.
La mémoire totale disponible sur une JVM est d'environ 2-4 Go pour une JVM 32 bits et le carré de ceci pour une JVM 64 bits (environ 4-16EB). Le JVM se sépare sa mémoire:
mémoire de tas Mémoire non-tas
voir http://docs.oracle .com / javase / 7 / Docs / API / Java / Lang / Gestion / MemoryMXBean.html et http://www.yourkit.com/docs/kb/size.jsp
existe-t-il une méthode par laquelle nous pouvons calculer la taille des piles d'appel de méthode de manière dynamique dans notre programme
Je vous recommande de ne pas faire ce que vous suggérez dans la question car:
Qu'est-ce que vous essayez de faire pourrait être un anti-modèle Un anti-motif est de ne pas penser à ces choses de manière appropriée pendant la conception et le développement et imaginez simplement que la magie d'introspection d'exécution pourrait couvrir pour cela. Il peut exister des applications (rares!) High-performance exigeantes qui nécessitent de réorganiser considérablement l'algorithme au moment de l'exécution pour correspondre exactement aux ressources découvertes - mais c'est complexe, laid et coûteux.
Et même à ce moment-là, il serait probablement préférable d'entraîner des modifications d'algorithme dynamique à un niveau de macro du paramètre "-XSS", plutôt qu'à un niveau micro-niveau de la consommation de mémoire exact de la pile à un emplacement dans le code.
Stackoverflow Exception
Stackoverflow Exception serait la meilleure réponse.
Une approche «correcte» serait de spécifier les exigences du programme, spécifiez l'environnement d'exécution requis (y compris la mémoire minimale / nécessaire!) Et concevez votre programme en conséquence pour une utilisation optimale des performances et de la mémoire.
Monsieur ce qu'une explication monsieur .... Excellent monsieur ..... Vous avez expliqué le concept très profondément ..... Merci monsieur. +1 pour vous .....
Sir j'ai sur la question "JVM est d'environ 2-4 Go pour une JVM 32 bits et le carré de ceci pour une JVM 64 bits (environ 4-16EB)". Monsieur pour 64 bits, il s'agit juste d'obtenir 4-16 Go.
N ° (2-4 000 000 000) octets carrés (taille adressable maximale). À votre santé
Merci monsieur, je pense que si vous êtes assis, c'est la meilleure réponse pour cette question.
Pour autant que je sache, la limite de la pile en Java est tout à fait abstraite et non destiné à la mesure. En fait, je pense que la taille de la pile varie d'une machine à base de plusieurs facteurs tels que la mémoire.
Je n'ai jamais eu un programme pour lancer une exception de débordement de pile, sauf pour les boucles infinies / récursivité. Je me gratter la tête à essayer de comprendre comment il serait même possible de lancer une exception de débordement de pile sans une boucle infinie. Si votre programme appelle que de nombreuses méthodes, alors il est probable la création d'objets simultanément, et vous êtes beaucoup plus susceptibles de recevoir une erreur OutOfMemory qu'une exception de débordement de pile sans boucle infinie.
En fait, ce que le diable serait le point d'une limite de pile qui pourrait limiter votre capacité à fonctionner correctement? Java a des limites de mémoire pour prendre soin de vous aller à la mer avec des ressources. Le but de débordement de la pile est de boucles de capture / récursion qui ont atteint de folie meurtrière et ont besoin d'être pris.
Le point que je suis en train de faire est: si des exceptions de dépassement de la pile peste vos tests unitaires, vous devriez vérifier ces boucles / fonctions récursives pour certains sur le comportement de contrôle. La pile d'appel est très, très long et je doute que vous avez atteint naturellement.
Nice ... merci +1 pour vous aussi.
Eh bien, vous pouvez utiliser quelque chose comme s'il existe en C avec le compilateur Microsoft C ++: une fonction spécifique (je ne me souviens pas du nom) qui s'appelle automatiquement sur chaque fonction de début et de fin.
Aussi, vous comptez le nombre d'appels et de sous-chiffres par incrément et décrémentez le compteur global après la fonction de démarrage et avant la fonction finale.
Par exemple, avec Microsoft .NET, vous pouvez insérer un appel de fonction pour incrémenter et décrémenter votre compteur mondial sur chaque appel. C'est Jit conçu.
Vous pouvez également utiliser une base de données NOSQL afin de stocker vos appels.
En outre, il y a une autre chose: utilisez un système de journal qui trace automatiquement vos appels.
En outre, lorsque votre pile d'appels est pleine, il est parfois causé par une fonction récursive. Avec quelques lignes de code et un objet, vous pouvez stocker une certaine propagation sur chaque fonction de chaque appel. Cette solution peut également être utilisée pour détecter n'importe quelle fonction une chose spéciale: "Qui m'appelle-t-il?"
Également, puisque Java est généré par des octets générés, vous pouvez détecter le code octet d'un appel de fonction et insérer avant l'appel de la fonction et après l'appel de la fonction pour ajouter votre pile personnalisé.
Des réponses de tous les développeurs Maven ?
@EJP Sir Maven Persers sont ceux qui sont toujours prêts à partager leurs connaissances, toujours prêts à aider les autres experts et expérimentés. C'est pourquoi je pense toujours aux membres de chaque stackoverflow en tant que développeurs maven.
Cela n'a pas de sens. Il y a une erreur intérieure. En tout cas, les gens peuvent mieux répondre à votre question sont Java Développeurs.
@Ejp Ok monsieur désolé. Merci de m'aider mais je ne sais pas comment résoudre la déclaration ayant un mot maven.
Mec quoi de neuf avec le monsieur ???
@Thihara ne comprend pas ce que tu veux dire.