Nombre maximal de Thread, consommation en ressource et solutions de remplacement

Bonjour à tous !

Je sais que c'est un problème qui a déjà été abordé, mais je ne parviens pas, après recherche, à trouver des réponses précises à mes questions. S'il en existe déjà et que je ne les ai pas vues, excusez-moi d'avance.

Voilà, je développe actuellement un serveur de socket en Java, pour un jeu en flash. Le jeu étant au tour par tour, mon serveur n'a pas besoin d'être ultra-réactif, mais je tente tout de même d'en minimiser au maximum la charge pour éviter les mauvaises surprises. Or, j'utilise beaucoup de threads.
Pour chaque joueur un thread est créé, et ensuite j'en utilise beaucoup comme "timer" (pour déclencher tel ou tel évènement au bout de tant de temps, par exemple pour vérifier qu'un joueur a bien reçu telle ou telle donnée, qu'il est bien actif régulièrement, etc). Donc je me retrouve rapidement avec une grosse grosse masse de thread, même si ceux-ci sont légers et principalement inactifs (ils dorment pendant tant de seconde, exécutent une petite fonction et se terminent).

Mes questions sont donc :
- Est-ce mauvais d'avoir trop de thread, notamment concernant la charge processeur, même si ceux-ci sont majoritairement endormis (ou en attente de recevoir des sockets, donc inactifs) ?
- Comment connaître le nombre maximum de thread que je peux exécuter simultanément ? Parce qu'en cas de grosse affluence, même si ceux-ci sont "légers", j'ai peur d'arriver à une limite qui ferait planter le server.
- Existe-t-il une alternative aux thread pour exécuter une action au bout d'un temps donné ? Je sais qu'il existe une classe Timer en Java, mais j'ai cru comprendre qu'elle utilisait elle-même un thread en interne, donc ça ne résoudrait en rien le problème.

Merci d'avance de vos réponses, n'hésitez pas à me dire si je n'ai pas été clair.

Citation:

---

Envoyé par Tetrix

- Est-ce mauvais d'avoir trop de thread, notamment concernant la charge processeur, même si ceux-ci sont majoritairement endormis (ou en attente de recevoir des sockets, donc inactifs) ?

---

Ce n'est pas mauvais pour la charge processeur, mais c'est mauvais pour la consommation mémoire. Chaque thread dispose d'une stack, qui fait entre 512k et 1M. Donc 2000 thread à 1M, tu consomme 2G juste parce que tu crée des threads...

Citation:

---

Envoyé par Tetrix

- Comment connaître le nombre maximum de thread que je peux exécuter simultanément ? Parce qu'en cas de grosse affluence, même si ceux-ci sont "légers", j'ai peur d'arriver à une limite qui ferait planter le server.

---

Ca dépend de la configuration de l'OS et de ta mémoire disponible (cf point précédent)

Citation:

---

Envoyé par Tetrix

- Existe-t-il une alternative aux thread pour exécuter une action au bout d'un temps donné ?

---

Si tes actions sont faciles à enchainer, une simple boucle

Code:

---

1 2 3 4 5 6 7 8

while(resteDesActionsAFaire){ Thread.sleep(tempsRestantAvantDeclanchementProchaineAction()) for (ActionAFaire a: listeActionAFaireRegulierement){ if (a.pourMaintenant()) a.faireLAction(); } }

---

est préférable à la création de N timers ;)
Pour des système plus complexes, tu peux regarder quartz, qui te permet de scheduler des jobs sur un nombre limité de threads. Genre 200 jobs sur 4 threads, chaque job prenant le premier thread disponible et le libérant dès l'action terminée.

Pour tes socket, tu peux aussi activer la lecture non blocante et traiter tes N sockets dans un seul Thread, à l'intérieur d'une boucle.


Si ton jeu travaille au tour par tour, il y a aussi le soucis que, si tu met disons 2000 thread pour gérer tes clients, à chaque fin de tour, tous ces threads vont se probablement se réveiller pour travailler en même temps. Du coup, sur une machine 8 coeurs, tu aura 250 threads / coeur, ce qui signifie que chaque thread ne disposera que de 4 millisecondes de temps de calcul par seconde...

Bonsoir, et merci pour cette réponse.

Je reviens un peu trois plombes après, mais j'ai fini par me remettre à cette tâche et ça m'a pris pas mal de temps de tout adapter.

Pour information, j'utilise maintenant quelques timers seulement qui gèrent des listes de tâches, grosso modo de la manière dont me l'a conseillé tchize_ (que je double remercie, donc).
J'ai donc divisé par trois le nombre de threads utilisés : je continue pour l'instant à en avoir un par connexion socket, car la lecture non-bloquante me semble difficile à mettre en place pour ce que je veux faire. J’espère donc que la réduction présente sera suffisante (et sinon, je trouverai une autre solution).

Bonne nuit à vous.