Un ou plusieurs pools de threads pour le serveur Java?

Question

J'écris une application de serveur Java assez complexe qui a une partie significative de traitement d'arrière-plan en plus du traitement de demande-réponse habituel. Une partie du traitement en arrière-plan est faite de façon cron à l'aide du cadre Quartz. D'autres tâches sont plus à la demande - si un nouveau client se connecte, il crée un travail supplémentaire pour la mise à jour de temps en temps. Les tâches cron peuvent également être variées - certaines surveillent les applications externes, d'autres calculent les statistiques, etc.

J'utilise un certain nombre de pools de threads pour exécuter toutes ces tâches avec l'idée que des tâches similaires partageront un pool de threads, mais que des tâches différentes n'en partageront pas. Par exemple, les tâches de surveillance ne seront jamais exécutées sur le pool de statistiques et les tâches statistiques ne seront jamais exécutées sur le pool de surveillance. D'autre part, je sais que certaines personnes préféreraient simplement avoir un seul pool de threads et tout faire fonctionner sans séparation.

Je me demande ce qui est considéré comme la meilleure pratique dans un tel scénario. Quels sont les avantages et les inconvénients de la séparation des pools de thread?

Cela importe-t-il même?

Answer 1

Il n'y a pas vraiment une réponse directe, mais une autre proposition :-(

Vos travaux de quartz peuvent être mis en pause, annulés et ainsi de suite, nous allons l'appeler « géré ». Je suppose que vous allez créer une interface utilisateur à les gérer.

Est-ce que vous vous rendez compte que vous vos autres emplois (« à la demande ») ne bénéficieront pas des mêmes fonctionnalités, à moins que vous le mettre en œuvre bien sûr? Avez-vous pensé faire tout un travail de quartz (même si elle commence immédiatement), pour obtenir un code uniforme?

Answer 2

La réponse dépend de la nécessité ou non de séparer les ressources d'application entre différents types d'activité. Par exemple, j'écris actuellement une application serveur composée de quelques auteurs à haut débit et potentiellement de nombreux lecteurs. Les lecteurs accèderont à l'application de manière sporadique, mais pourraient potentiellement demander beaucoup de données (c'est-à-dire des demandes de longue durée). Je dois m'assurer que les écrivains ne sont jamais affamés, donc je vais utiliser deux pools de threads dans ma conception pour lire/écrire. Si le pool de threads du lecteur est temporairement épuisé, les rédacteurs ne seront pas affectés; seules les demandes de lecture seront retardées.

Une alternative aurait été d'utiliser un PriorityQueue en conjonction avec un ThreadPoolExecutor et d'attribuer une priorité plus élevée aux demandes d'écriture. Donc, en conclusion - Mon conseil serait: Commencez avec un pool de threads et ne faites que rendre votre design plus complexe s'il y a une raison concrète de le faire.