Création de thread d'application Java

Question

Je travaille sur une application Java. Nous utilisons Spring et l'application exécute le serveur d'applications WebSphere. Tout au long de l'application, nous conservons plusieurs pools de threads créés dans l'application à l'aide de Spring. Comme ci-dessous et jusqu'à présent, nous n'avons eu aucun problème avec cela.

<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor"> 
     <property name="maxPoolSize" value="100"/> 
     <property name="corePoolSize" value="10"/> 
</bean> 

Mais je lisais docs de référence du cadre de printemps où je suis tombé sur le paragraphe ci-dessous,

34.3.3 implémentations TaskScheduler

Comme avec l'abstraction TaskExecutor de printemps, le principal avantage de le TaskScheduler est que le code reposant sur le comportement de planification n'a pas besoin d'être couplé à une implémentation de planificateur particulière. La flexibilité que ce fournit est particulièrement pertinente lors de l'exécution dans l'environnement d'application Server où les threads ne doivent pas être créés directement par l'application elle-même. Dans ce cas, Spring fournit un TimerManagerTaskScheduler qui délègue à une instance CommonJ TimerManager , généralement configuré avec une recherche JNDI.

réf. https://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html

donc ma question est si je ne me soucie pas d'avoir accès à Java EE des informations contextuelles, quelles autres raisons sont là pour utiliser des pools de threads gérés? En gros, je me demande quelle est la meilleure pratique et si avoir un thread géré par l'application est totalement inacceptable.

Answer 1

Généralement, les pools de threads (ainsi que les connexions JDBC) sur les serveurs d'entreprise tels que WebSphere ne doivent pas être gérés par une application mais par le serveur lui-même. Spring fournit uniquement une interface entre votre application et le modèle de pool de threads du serveur.

Le principal avantage de la configuration des pools de threads côté serveur est l'efficacité: dans le passé, plusieurs applications étaient généralement déployées sur le même serveur. Avec le pool de threads partagé, il est possible d'utiliser toutes les ressources du serveur. De nos jours, garder plusieurs applications sur le même serveur Java est considéré comme une mauvaise pratique (à la lumière de l'architecture des microservices). Considérez simplement ces pools de threads comme faisant partie de la pile technologique héritée.