En général, les threads inactifs supplémentaires en Java ne posent pas de problème. Mais dans un environnement aux ressources limitées, et plus particulièrement si votre logiciel utilise déjà beaucoup de threads, un trop grand nombre de threads supplémentaires peut surcharger le système.
Google Cloud PubSub est un excellent framework de communication asynchrone, réputé pour sa légèreté. Pourtant, dès la première utilisation, le client Java de Google PubSub crée 60 threads qui restent actifs en permanence. (Vous pouvez visualiser l'ensemble des threads via Thread.getAllStackTraces().keySet().) Ces threads supplémentaires servent aux opérations asynchrones liées à la publication de messages.
Trop de threads
Ces threads s'avèrent utiles pour un publisher à fort volume ; en revanche, pour un publisher à faible volume, 60 threads, c'est largement excessif.
L'API qui permet de définir le nombre de threads ne fait pas partie de l'API officielle de PubSub, reste peu documentée et plutôt bas niveau. Voici donc la marche à suivre.
1. Définissez setExecutorThreadCount sur une petite valeur, par exemple 4 (voire 1), comme ci-dessous. Cela réduit le nombre de threads d'environ 40.
2. Il reste alors une vingtaine de threads inactifs. Vous pouvez les réduire selon la méthode documentée par ajaaym sur GitHub (code ci-dessous).
Ici, vous créez vos Publisher, GrpcTransportProvider et ManagedChannelBuilder avec un unique ExecutorProvider partagé à un seul thread, de sorte qu'un seul thread soit ajouté au total pour le PubSub Publisher.