J'ai plusieurs threads chacun avec sa propre file d'attente privée simultanée et tout ce qu'ils font est de gérer une boucle infinie de messages de celui-ci. Il pourrait arriver que l'une des files d'attente ne reçoivent pas de messages pendant une période de temps (peut-être quelques secondes), et ils pourraient aussi se produire dans de grandes rafales et une transformation rapide est nécessaire.
J'aimerais savoir ce qui serait le plus approprié à faire dans le premier cas: Utilisez une file d'attente de blocage et bloquez le fil jusqu'à ce que j'ai davantage d'entrées ou que je fais un fil.yield ()?
Je souhaite avoir autant de ressources de processeur disponibles dans la mesure du possible à un moment donné, car le nombre de threads simultanés peut augmenter avec le temps, mais je ne veux pas que le traitement du message tombe derrière, car il n'y a pas de garantie de Lorsque le thread sera reeschedulé pour l'exécution lors d'un rendement (). Je sais que le matériel, le système d'exploitation et d'autres facteurs jouent ici un rôle important ici, mais je mets de côté et en regardant à partir d'un point de vue Java (JVM?), Quel serait le plus optimal?
4 Réponses :
Il suffit toujours de bloquer les files d'attente. Java cède dans les files d'attente en interne.
En d'autres termes: Vous ne pouvez obtenir de prestation de performance dans les autres threads si vous cédez dans l'un d'entre eux plutôt que de simplement bloquer.
Non, juste essayer Perruptor Bibliothèque. Semble meilleure performance n'a que le rendement!
Vous voulez certainement utiliser une file d'attente de blocage - elles sont conçues pour exactement cet objectif (vous voulez que vos fils ne puissent pas utiliser le temps de la CPU lorsqu'il n'y a pas de travail à faire).
thread.yield () est une bête extrêmement tempéramente - le planificateur joue un rôle important dans exactement ce qu'il fait; et une implémentation simple mais valide consiste simplement à ne rien faire.
Vous pouvez également envisager de convertir votre implémentation pour utiliser l'un des exécutantservice implémentations - probablement threadpoolexecutor .
Cela peut ne pas être approprié pour votre cas d'utilisation, mais si tel est le cas, il supprime toute la charge de vous inquiéter de la gestion de thread à partir de votre propre code - et ces questions sur cédant ou non simplement disparaissent.
En outre, si de meilleurs algorithmes de gestion des threads émergent à l'avenir - par exemple, quelque chose d'apprécier Grand Centre Dispatch - Vous pourrez peut-être convertir votre application pour l'utiliser avec presque aucun effort.
Une autre chose que vous pourriez faire est d'utiliser la carte de hachage simultanée pour votre file d'attente. Lorsque vous faites une lecture, il vous donne une référence de l'objet que vous recherchiez, il vous est donc possible de vous manquer un message qui a été mis dans la file d'attente. Mais si tout cela fait, c'est écouter un message que vous allez attraper la prochaine itération. Ce serait différent si les messages pouvaient être mis à jour par d'autres threads. Mais il ne semble pas vraiment y avoir une raison de bloquer que je peux voir.