En Java, Comment puis-je m'assurer que mon application Web est sûre pour les threads?

Question

Comment puis-je m'assurer que mon application Web de servlets Java est sûre pour les threads? Que dois-je faire en ce qui concerne les variables de session, les variables statiques d'une classe ou tout autre élément pouvant poser un problème de sécurité des threads?

Answer 1

Fait: il n'y a que 1 instance d'un servlet dans les années webapp durée de vie. Il est créé au démarrage de webapp et il est détruit lors de l'arrêt de webapp. Voir également this answer pour une interprétation approximative.

Ainsi, il a été partagé entre toutes les demandes (threads). Si vous affectez des données de requête ou de session en instance (ou pire, comme static) variable, il n'est définitivement pas sécurisé, car il est ensuite partagé entre toutes les demandes (threads) de tous les utilisateurs (sessions) dans l'ensemble de l'application. Vous avez juste besoin de les assigner comme variables locales de méthode pour les garder threadsafe. Donc:

public class MyServlet extends HttpServlet { 

    private Object thisIsNOTThreadSafe; 

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
     Object thisIsThreadSafe; 

     thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests! 
     thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe. 
    } 
} 

C'est essentiellement tout ce dont vous avez besoin de prendre en compte lors du développement de servlets avec la sécurité des threads en tête.

Ensuite, il y a des attributs de session (HttpSession) qui peuvent être partagés entre plusieurs demandes du même utilisateur, mais dans le monde réel, vous n'avez pas à vous soucier de la synchronisation de l'accès aux sessions. Vous n'y mettez normalement que des données spécifiques à l'utilisateur, telles que l'utilisateur connecté, les préférences spécifiques à l'utilisateur, le panier d'achat, etc. Vous devez juste vous assurer que vous ne mettez pas de données de portée pure dans la portée de la session. Cela se refléterait dans plusieurs fenêtres/onglets du navigateur à l'intérieur de la même session.

Ensuite, il existe des attributs d'application (ServletContext) partagés par tous les utilisateurs de l'application, mais vous ne stockez normalement que des constantes et autres données statiques, comme la configuration webapp, DAO factory, dropdownlist content, etc.Tout cela peut être fait avec un ServletContextListener, voir aussi this answer pour un exemple de base. Vous devez juste vous assurer que vous ne mettez pas de données de portée de session ou de demande pure dans la portée de l'application.

Answer 2

Voulez-vous dire dans un contexte par opposition à toute autre application Java? Il n'y a vraiment pas beaucoup de différence. Chaque requête à une servlet amène le conteneur à émettre un nouveau thread pour le gérer, donc les variables d'instance dans le servlet doivent être thread-safe. Il est préférable de gérer tout votre business avec des variables locales dans les méthodes doGet/doPost(). Il y a un truc auquel je peux penser. Avec les variables de session, il se peut que l'utilisateur ait deux fenêtres de navigateur ouvertes, toutes deux pointant vers votre application. Dans ce cas, vous devrez également surveiller la sécurité des threads avec la portée de la session.

Answer 3

Wow, c'est une question chargée. Pour simplifier, vous devez vous assurer que l'accès à toutes les données partagées est soigneusement synchronisé. Par exemple, vous pouvez synchroniser l'accès à une variable statique avec un mutex ou une fonction synchronisée.

Notez que vous devrez peut-être également synchroniser à des niveaux plus élevés si vous avez besoin de transactions atomiques qui modifient plusieurs ressources partagées en même temps.

La conception d'une application concurrente n'est pas simple, et il n'y a pas de solution miracle (malheureusement). Je recommande fortement le livre "Java Concurrency in Practice" pour plus d'informations sur l'écriture de code concurrent sécurisé.

Answer 4

• ne pas utiliser les variables d'instance de servlets et les filtres
• ne pas utiliser les variables statiques
• read this article on session thread safety
• pensent