Java DataInputStream.read() entraînant 20% d'utilisation CPU constante pendant le blocage.

Question

J'ai une application côté serveur ouvre un thread socket pour chaque client connecté. J'ai un DataInputStream dans chaque thread, qui appelle read (byte [] array) pour lire les données. Je définis également le délai d'attente de socket à quelques minutes. Le code principal est quelque chose comme ceci:

while (dataInputStream.read(array) != -1) { do something... } 

Cependant, après plusieurs heures de fonctionnement, en jconsole avec plugin topthreads, je peux voir plusieurs threads clients utilisent CPU ish 20% chacun. Si je clique dessus, la pile d'appels montre que le thread est bloqué sur la ligne ci-dessus, sur la fonction read().

Je sais que la fonction read() bloquera normalement pour attendre les données. Lorsqu'il est bloqué, il consomme peu de cycles CPU. Maintenant, il utilise 20% ish chacun et mon serveur est de plus en plus lent lorsque plus de threads ont le même problème. Mon serveur a environ 5 demandes de connexion par seconde, ce qui arrive très rarement car en quelques heures seulement 5 threads ont le problème.

Je suis vraiment confus. Est-ce que quelqu'un peut m'aider?

Answer 1

quand jvm attend de lire les données à partir d'une prise il y a beaucoup plus d'activités que le système doit faire en permanence ..

Je n'ai pas la technique exacte utilisée, mais this link devrait donner une idée ..

pourquoi n'essayez-vous pas d'utiliser un BufferedInputStream ou l'un des StreamReader s .. ces classes aideraient dans la performance. Vous pourriez essayer d'utiliser les classes du paquetage java.util.concurrent pour améliorer la gestion des threads (la création d'un pool de threads aiderait à réduire la quantité totale de mémoire consommée, contribuant ainsi aux performances globales du système). Vous ne savez pas si vous le faites cela déjà

Answer 2

while (dataInputStream.read(array) != -1) { do something... } 

Ce code est erroné quand même. Vous devez stocker la valeur de retour de read() dans une variable afin de connaître le nombre d'octets renvoyés. Le reste de votre application ne peut probablement pas fonctionner de manière fiable sans cela de toute façon, donc il est très prématuré de s'inquiéter du timing à ce stade.

Cependant, à moins que le tableau ne soit exceptionnellement petit, je doute que vous utilisiez ici 20% de CPU. Plus probablement 20% de temps écoulé est dépensé ici. Le blocage sur une lecture réseau n'utilise pas de CPU.