Travailler avec JSON en Go : analyse et sérialisation pour débutants

Pourquoi les servlets font-ils encore peur, et comment y faire face ?

Si vous avez déjà parcouru Stack Overflow à la recherche d'une réponse à la question "Comment fonctionnent les servlets ?", vous êtes probablement tombé sur un fil légendaire avec des milliers de vues. La question y est posée maintes et maintes fois : "Combien d'instances de servlet sont créées ? Comment partager des données entre les requêtes ? Et pourquoi ma variable se comporte-t-elle de façon étrange ?"

Soyons honnêtes : les servlets ne sont pas de la science spatiale, mais il y a beaucoup d'embûches. Surtout en ce qui concerne le multithreading et les variables partagées. Dans cet article, nous ne nous contenterons pas de répéter la documentation. Nous allons prendre un exemple concret, le décomposer pièce par pièce, et vous montrer comment éviter les erreurs courantes. C'est parti !

Comment un servlet entre en mémoire : instanciation et cycle de vie

Commençons par les choses simples : combien d'instances de servlet sont créées ? La réponse : une. Oui, vous avez bien entendu. Le conteneur de servlets (Tomcat, Jetty, etc.) crée exactement une instance de chaque servlet pour l'ensemble de l'application. Et cette instance vit jusqu'à ce que l'application soit déchargée.

Voici à quoi ressemble un cycle de vie typique :

\n
• init() — appelée une fois lorsque le servlet est chargé. Ici, vous initialisez les connexions à la base de données, les configurations, etc.
\n
• service() — appelée pour chaque requête entrante. C'est là que le traitement a lieu.
\n
• destroy() — appelée avant que le servlet ne soit déchargé. Libérez les ressources.
\n

Le point clé : service() (et ses dérivés doGet, doPost) est exécutée dans un thread séparé pour chaque requête. Cela signifie que la même instance de servlet gère des centaines de requêtes simultanément. Et c'est là que les choses deviennent intéressantes.

Exemple : un servlet, plusieurs threads

@WebServlet("/counter")\npublic class CounterServlet extends HttpServlet {\n    private int counter = 0;  // variable partagée !\n\n    @Override\n    protected void doGet(HttpServletRequest req, HttpServletResponse resp) \n            throws ServletException, IOException {\n        counter++;\n        resp.getWriter().write("Compteur : " + counter);\n    }\n}

Si vous exécutez ce code et envoyez 10 requêtes parallèles, vous n'obtiendrez pas les nombres de 1 à 10 dans l'ordre. Au lieu de cela, vous verrez quelque chose comme : 2, 5, 3, 8, 1... Ou le counter pourrait même sauter des valeurs. Pourquoi ? Parce que counter++ n'est pas une opération atomique. Deux threads peuvent lire la même valeur, l'incrémenter et la réécrire, perdant ainsi une incrémentation.

Conclusion : les champs d'instance de servlet sont des variables partagées. Ils sont visibles par tous les threads. Et si vous ne synchronisez pas l'accès à ceux-ci, vous obtiendrez une condition de concurrence.

Sessions : comment ne pas mélanger les utilisateurs

Imaginez maintenant : vous voulez stocker des données propres à chaque utilisateur (panier d'achat, connexion, paramètres). Pour cela, les servlets Java fournissent HttpSession. Une session est créée pour chaque nouvel utilisateur et vit jusqu'à ce qu'il ferme le navigateur ou que le délai d'expiration expire.

Une session n'est pas une mémoire partagée. Chaque utilisateur obtient sa propre instance de session. Mais à l'intérieur de la session, vous pouvez stocker n'importe quels objets, et ils ne seront accessibles qu'à cet utilisateur.

Exemple : travailler avec une session

@WebServlet("/session-demo")\npublic class SessionServlet extends HttpServlet {\n    @Override\n    protected void doGet(HttpServletRequest req, HttpServletResponse resp) \n            throws ServletException, IOException {\n        HttpSession session = req.getSession();\n        Integer visitCount = (Integer) session.getAttribute("visitCount");\n        if (visitCount == null) {\n            visitCount = 0;\n        }