Je développe un servlet Java qui en cours d'exécution, démarre différentes méthodes d'objets dans de nouveaux threads. Ces threads doivent accéder à une variable décrivant l'instance de servlet spécifique, disent que Jobid. Pour cette raison, j'ai déclaré la variable Jobid comme statique. Le constructeur de servlet calcule cette valeur pour chaque instance de servlet (appel). J'étais erré si le servlet est appelé à quelques reprises en même temps, la variable statique junkid est partagée entre les appels, ce qui signifie que certains threads obtiendront le mauvais Jobid, ou il est calculé une fois pour chaque appel. Un servlet spécifique démarré utilisera le JOBID calculé pour ce servlet spécifique (qui est la façon dont je veux qu'il fonctionne). Des idées? Merci beaucoup!
4 Réponses :
Vous devez obtenir votre propre valeur une connexion et la stocker ailleurs.
statique signifie que chaque instance accédera à la même valeur.
Donc, chaque utilisateur connecté au servlet accédera à la même valeur. Votre Jobid sera probablement faux lorsque 2 utilisateurs ou plus sont connectés ensemble.
Les variables statiques sont partagées. Les variables statiques n'appartiennent à aucune instance, elles sont accessibles par toutes les instances de la classe. Lorsque vous utilisez un constructeur, il est utilisé pour créer un objet (une instance de la classe), la définition d'une variable statique dans un constructeur n'a généralement pas de sens car c'est quelque chose qui est en dehors de la portée de l'objet que vous créez. .
Quant à ce qui fonctionnerait, vous pouvez mettre le JOBID dans le HTTPSession et que chaque utilisateur en aurait sa propre copie.
Un servlet est créé uniquement une fois sur le démarrage de WebApp et partagé entre toutes les demandes. Statique ou non, chaque variable de classe / d'instance va être partagée entre toutes les demandes / sessions. Vous ne souhaitez pas attribuer des données de demande / session. Plutôt déclarer / attribuer-leur comme une variable méthodallocale. Par exemple,
public class MyServlet extends HttpServlet {
private static Object thisIsNotThreadsafe;
private Object thisIsAlsoNotThreadsafe;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Object thisIsThreadsafe;
thisIsNotThreadsafe = request.getParameter("foo"); // BAD! Shared among all requests.
thisIsAlsoNotThreadsafe = request.getParameter("foo"); // BAD! Shared among all requests.
thisIsThreadsafe = request.getParameter("foo"); // Good.
}
}
Et si j'utilise une variable finale statique privée? Pour des valeurs constantes. Ce serait bien?
@Mommawn: Ils ne sont pas mutables de toute façon, c'est bien. Le problème ne se produit que lorsque vous affectez des variables locales à des déclarations variables d'instance. Avec des constantes qui n'est déjà pas possible.
La stratégie d'instanciation des servlets n'est pas définie dans la spécification de servlet (aussi loin que je peux me rappeler, n'importe quoi, mais le comportement habituel semble être de ne créer qu'une seule instance par configuration de servlet. Donc, dans votre cas, chaque demande utiliserait la même variable.
Si j'étais vous, je envisagerais d'envoyer le mode JOBID comme paramètre sur le refacteur loin des variables statiques telles que ceci: plus facile à lire, Pas de problèmes de concurrence - Victoire pure. exécutable S. Vous utilisez les threads. avec. Par exemple, à condition de ceci:
Il est certainement décrit dans la spécification de servlet. Lisez le chapitre 2.3. De plus, les fils de frai dans un servlet doivent être effectués avec un soin élevé. Tant que l'exigence fonctionnelle de l'OP n'est pas claire et que son niveau de compétence représenté aussi loin est faible, je ne recommanderais pas de faire cela. Cela ne conduirait à plus de confusion et de problèmes. Il suffit de stocker dans la portée de la session ou le passage / retenir en tant que paramètre de demande est plus que suffisant.
Vraiment, évitez de faire quelque chose de mutable
statique (qui inclut des singletons).