Je développe une application Web en utilisant Java/JSP. Une classe, par exemple Student, a un membre statique static private int _nextID;Portée du membre statique de la classe Java
Je veux savoir, si ce _nextID est le même parmi toutes les sessions utilisateur? Ou chaque session a son propre _nextID?
Dans le cas simple, vous pouvez supposer que plusieurs instances de Student partagent le même champ statique nextID. Cependant, il faut penser au-delà du cas simple (ou du document que vous n'avez pas). Dans ce cas, c'est bon à moins que les champs id de l'instance dérivés du compteur nextID se propagent dans une application plus grande où les ID sont censés être uniques. Dans ce cas, vous voulez un générateur d'ID plus robuste (peut-être que vous voulez un UUID, peut-être que vous voulez une clé primaire dans une base de données, peut-être quelque chose d'autre).
Demandez-vous soigneusement quelle est la portée requise des ID uniques. Recherchez ensuite une solution qui résout ce problème et documentez-le dans la classe.
En général, les champs statiques dans le même nom de classe, mais chargée par différents classloaders (dans le même ou dans différentes JVMs) peut être different instances, something people most often notice when trying to implement the Singleton pattern. Ainsi, la portée de votre variable statique dépend (dans des cas compliqués) sur les chargeurs de classe pertinents. Quelques plus (récent) détail sur Java namespaces defined by classloader is here et here.
Relatif à SO: Difference between Thread.getContextClassLoader()....
Cela dépend du conteneur de l'application et de la configuration. Un membre statique sera le même pour toutes les sessions s'exécutant dans une instance JVM, mais votre configuration peut créer plusieurs instances.
Si vous voulez que cela reste cohérent et portable, vous ne devez pas compter sur la même chose pour toutes les sessions. Cela peut également vous permettre de mettre à l'échelle plusieurs machines si nécessaire sans modifier ce code.
-1 non vrai; Les instances 'static' sont par classloader, pas par application/JVM – sleske
Ah bon point, c'est ce que je voulais dire, mais tapé la mauvaise chose. Merci pour la correction, on dirait que quelqu'un d'autre a eu une réponse avec ça. –
Clarification: * chargé par différents classloaders * - si les sessions sont réparties entre différentes JVM, il est presque certain que les données statiques ne seront * pas * partagées comme prévu (je ne serais pas surpris de trouver un cache distribué spécial/classloader contre-exemple ...). –