J'ai une application multi-threadé qui passe bien pour commencer, mais en cours d'exécution sur un serveur 16-CPU, une fois que je dépasse 5 ou 6 threads matériels, les niveaux de performance éteint. Je Suspect que le goulot d'étranglement entoure l'une des méthodes synchronisées. Cependant, je dois être sûr que c'est la méthode de culpabilité avant de commencer à plonger dans le code et d'essayer de remplacer l'algorithme avec un non-bloquant.
En cours d'exécution Java avec l'argument -XProf me dit que, comme je m'y attendais, les threads dépensent la majeure partie de leur temps bloqué. Y a-t-il une façon de pouvoir briser cela dans combien de temps ils passent bloqués à une méthode particulière ?
4 Réponses :
L'outil Jvisualvm fourni avec le JDK peut vous aider un peu, bien que ses informations de profilage de la CPU soient plutôt limitées (plus d'un visualiseur pour les données XProf). Je trouve généralement plus utile pour le profilage de la mémoire.
JProfiler a un joli profileur de processeur avec une fonctionnalité vraiment cool qui pourrait vous aider, mais c'est commercial.
ou, vous pouvez ajouter des statistiques de collecte à votre code (par exemple, mesurer combien de temps il faut pour exécuter chaque méthode synchronisée que vous soupçonnez, ce qui l'attend en attente de synchronisation / temps exécutant la méthode), bien que c'est beaucoup plus de travail. .
Pourriez-vous essayer Cette méthode ? Si cela fonctionne à travers plusieurs processeurs, il devrait trouver le problème, mais c'est un gros "si".
Fondamentalement, lorsque vous voyez qu'un thread est bloqué, la pile d'appel vous dit exactement pourquoi. Si vous ne savez pas si vous voyez le vrai problème, faites-le quelques fois.
Eclipse TPTP est un autre profileur très bon et libre.
http://yourkit.com La vue du moniteur vous indiquera quelles classes de verrou sont chaudes, qui tient le contenu. Serrures et ventilation par l'instance de verrouillage et la pile d'appelants. Il y a une période d'évaluation de 30 jours de l'outil.