avec des méthodes d'instance normale, les variables locales sont en sécurité du fil.
Si j'ai ce qui suit dans une méthode statique: serait-ce le fil-faire? Y a-t-il des attractions? Aussi, qu'est-ce que cela signifie exactement quand chaque variable a sa propre pile? Cela signifie-t-il sa propre structure? merci
4 Réponses :
Si les lignes que vous avez postées sont à l'intérieur de la méthode, il n'y a aucune raison pour laquelle il ne devrait pas être threadsafe. Les threads ne sont pas interagissants de quelque manière que ce soit - chaque fil voit un La prise vient si vous essayez de partager la valeur de I entre les threads, par exemple en effectuant En ce qui concerne votre deuxième question, chacun thread a sa propre pile, pas chaque variable. i .
i un champ statique. Ensuite, il est possible d'obtenir une condition de course où vous obtenez différents résultats en fonction du chronométrage.
Voici une démonstration avec un exemple (simpliste) pour aider à développer sur quelle marque a déclaré: la sortie:
3
3
3
3
3
3
3
3
3
3
3
Réponse courte est oui la méthode suivante est la sécurité du thread:
StackFrameForCalculcateSomething s = new StackFrameForCalculateSomething(); s.returnAddress = instructionPointer; s.number = 10; callStack.push( s ); s.invoke(); StackFrameForCalculcateSomething s2 = new StackFrameForCalculateSomething(); s2.returnAddress = instructionPointer; s2.number = 20; callStack.push( s2 ); s2.invoke();
Tout d'abord, je suppose que "Threadsafe" Vous voulez dire "se comporter comme si certaines opérations sont atomiques lorsque des mutations se produisent sur plusieurs threads." Si ce n'est pas ce que vous voulez dire par "threadsafe", veuillez définir soigneusement "Threadsafe" avant de poser des questions à ce sujet. Il semble que presque tous ceux qui posent des questions sur la sécurité du thread sur la dépassement de pile ont une définition personnelle différente pour ce que cela signifie.
Deuxièmement, les variables locales sont pas threadsafe . En particulier, les variables locales qui sont fermées de variables extérieures d'une méthode lambda ou anonyme, ou qui sont à l'intérieur d'un bloc d'itérateur, ne sont pas garanties pour être threadsafe lorsqu'il est muté sur plusieurs threads.
variables locales qui ne sont pas fermées de variables extérieures d'une fonction anonyme et qui ne sont pas dans un bloc d'itérateur ne peuvent être mutées que par le thread de courant et sont donc sans danger d'être mutés par plusieurs threads à la fois.
Aussi, qu'est-ce que cela signifie exactement quand chaque variable a sa propre pile?
Je n'ai aucune idée de ce que cela signifie; variables ne pas avoir de piles. threads ont des piles.
Voir: Stackoverflow.com/Questtions/420895/... La capture serait si
i n'était pas une variable locale.Ou s'il avait un autre objet là-bas qui a fait filer des choses dangereuses, comme définir des champs statiques sans verrou ni quelque chose. Par logique, sa méthode ne serait pas du thread en sécurité non plus. Mais c'est plus une exception délicate :)
Bon commentaire Skurmedal. Merci pour le lien Seth, malheureusement, je ne comprends parfois pas que les liens associés montaient avant un petit moment après avoir soumis mon message.