8
votes

Est-ce que java.lang.reflect.Method thread Safe?

est java.lang.reflect.method Safe Safe?

Le résultat du profilage de mon programme a montré que classe.getMethod () a pris beaucoup de temps d'informatique lorsqu'il est appelé plusieurs fois, un peu plus que prévu. Je peux appeler cela une fois et stocker la méthode résultante quelque part facilement accessible. Mais ensuite, plusieurs threads de travailleurs Web utiliseront l'objet de méthode stocké simultanément.

est-ce sûr?


0 commentaires

3 Réponses :


5
votes

Les classes Java ne sont garanties qu'une fois par instance de classier, vous pouvez donc supposer que la définition, y compris les méthodes et leurs signatures ne changeront pas le temps, vous pouvez donc les "mettre en cache" en toute sécurité pour une utilisation par plusieurs threads.

Cependant, gardez à l'esprit que les classes avec le même nom pleinement qualifié (package + nom de classe) peuvent être définies différemment par des instances de classier distinctes.


0 commentaires

0
votes

La définition de la classe ne va pas changer, alors si vous ne chargez que des classes différentes dans différents threads (à partir de bibliothèques distinctes, par exemple), l'objet méthode doit être le fil de sécurité. (Bien sûr, si la méthode qu'elle elle-même est appelée par réflexion est une question de sécurité différente.)


0 commentaires

7
votes

La méthode est sûre d'utiliser Accross Plusieurs threads à condition que vous ne modifiez pas l'état de la méthode après la rendant disponible sur plusieurs threads.e.g. Vous pouvez appeler de manière consactive (true) et paramétrée (FALSE) dans deux threads et le résultat ne serait pas en sécurité. Cependant cela n'a pas vraiment une bonne utilisation.

En bref, méthode.SetAccessable () n'est pas une sécurité technique en toute sécurité, mais vous devriez pouvoir l'utiliser dans un fil de fil de fil.


4 commentaires

Au fait, n'est-ce pas SETPESSIBLE une fuite de sécurité? Si un code a le droit de définir quelque chose accessible, un autre code peut venir et utiliser la méthode privée sans plus de contrôle de sécurité.


À moins que votre SecurityManager ne l'empêche, vous pouvez accéder à des méthodes protégées et locales et privées. Il améliore la performance d'accès des méthodes même publiques en remplaçant les chèques.


Oui, je parle d'un cas avec Security Manager installé ... et des privilèges différents pour différentes parties du code. Mais je ferai mieux d'ouvrir une autre question à ce sujet que d'utiliser les commentaires à une question non liée à cela.


Ah, vient de faire des expériences: en fait, chaque objet (ou champ / constructeur) a son propre état accessible et sur chaque appel à getMethod () etc. Vous en obtenez un nouveau. Ainsi, tant que vous ne partagez pas cet objet avec le code non approuvé (ou donnez à ce code non approuvé une nouvelle copie non accessible), vous êtes bon.