Je suis relativement nouveau sur Java et mon expérience se limite aux applications Web fonctionnant sur un conteneur Web (Jboss dans mon cas).
Ai-je raison de dire que pour les applications Web, le conteneur Web prend en charge le multi-threading? Si oui, puis-je introduire de nouvelles marches dans une application Web? Y a-t-il un avantage à le faire et dans quel scénario faudrait-il le faire?
Réponses:
Ai-je raison de dire que pour les applications Web, le conteneur Web prend en charge le multi-threading?
La plupart des serveurs Web (Java et autres, y compris JBoss) suivent un modèle "un thread par requête", c'est-à-dire que chaque requête HTTP est entièrement traitée par exactement un thread. Ce thread passera souvent la plupart du temps à attendre des choses comme les requêtes DB. Le conteneur Web créera de nouveaux threads si nécessaire.
Certains serveurs (dans l'écosystème Java principalement Netty ) effectuent le traitement des demandes asynchrones, soit avec un modèle «un thread fait tout», soit quelque chose de plus complexe. L'idée de base est que le fait d'avoir beaucoup de threads en attente gaspille des ressources, donc travailler de manière asynchrone peut être plus efficace.
Si oui, puis-je introduire de nouvelles marches dans une application Web?
C'est possible, mais cela doit être fait très soigneusement, car les erreurs (comme les fuites de mémoire ou la synchronisation manquante) peuvent provoquer des bogues très difficiles à reproduire ou faire tomber l'ensemble du serveur.
Y a-t-il un avantage à le faire et dans quel scénario faudrait-il le faire?
Eh bien, l'avantage est que vous pouvez faire des choses en parallèle. L'utilisation de threads pour améliorer la vitesse de calcul pure est quelque chose que vous ne devriez pas faire sur un serveur Web, car cela ralentirait le traitement des autres requêtes. Ce genre de chose devrait être fait sur un serveur séparé, probablement à l'aide d'une sorte de file d'attente de travaux.
Un scénario légitime pour le multithreading dans le contexte de la gestion d'une requête HTTP pourrait être si vous avez besoin d'accéder à d'autres ressources réseau, par exemple appeler plusieurs services Web différents. Si vous le faites en une seule fois, vous devez attendre que chaque appel se termine à son tour. Mais si vous utilisez plusieurs threads, le temps d'attente total n'est que le retard de l'appel le plus lent.
En réponse à votre question:
En quoi le multi-threading est-il différent dans une application Web basée sur Java par rapport à une application Java autonome
Ce n'est pas différent. Habituellement, les applications Web logicielles sont conçues pour fournir un certain multithread déjà en faisant de chaque nouvelle demande un thread. Par vous pouvez utiliser / créer des threads comme vous le feriez pour n'importe quelle autre application.
En effet, le multi-threading peut vous permettre d'augmenter considérablement les performances si vous l'utilisez correctement. Pour les tâches intensives d'E / S telles que l'accès au réseau et l'accès au lecteur de disque, l'augmentation des performances est presque toujours garantie. Pour les tâches gourmandes en calcul, vous devez respecter la règle d'un thread par cœur sur le serveur. Par exemple, si votre cœur possède un processeur i7, vous devez vous en tenir à 7 threads pour effectuer des tâches de calcul.
En réponse à votre question:
Y a-t-il un avantage à le faire et dans quel scénario faudrait-il le faire?
Michael Borgwart dit que vous ne devriez pas faire cela pour améliorer la vitesse de calcul. Je ne suis pas d'accord, car cet article suggère que le multithread peut aider à fournir une réactivité lorsque les utilisateurs ont besoin d'une tâche de calcul lourde. Dans un anglais simple, les utilisateurs n'auront pas à attendre aussi longtemps pour effectuer des tâches de calcul lourdes avec le multithread.
Si vous avez l'intention d'utiliser beaucoup de threads, je vous suggère d'utiliser un pool de threads. Cela réduira les frais généraux de création de threads.
Eh bien, c'est une bonne question et je pense que la plupart des développeurs qui travaillent dans le développement d'applications Web n'utilisent pas le multithreading explicitement. La raison est assez évidente puisque vous utilisez un serveur d'applications pour déployer votre application, le serveur d'applications gère en interne un pool de threads pour les demandes entrantes.
Alors pourquoi utiliser le multithreading de manière explicite? De quoi a besoin un développeur d'applications Web pour s'exposer au multithreading?
Lorsque vous travaillez sur une application à grande échelle où vous devez gérer plusieurs demandes simultanément, il est difficile de traiter chaque type de demande de manière synchrone, car un type particulier de demande aurait pu effectuer un traitement important, ce qui aurait pu réduire les performances de votre application.
Prenons un exemple où une application Web après avoir servi un type particulier de demande doit informer les utilisateurs par e-mail et SMS. Le faire de manière synchrone avec le thread de demande pourrait réduire les performances de votre application Web. Voici donc le rôle de la lecture mutuelle. Dans de tels cas, il est conseillé de développer une application autonome multithread sur le réseau qui est uniquement responsable de l'envoi d'e-mails et de SMS.
Concurrency Utilities.