Nous avons une petite boîte de texte avec 512 Mo de RAM. Nous voulions voir combien de threads nous pouvons créer en Java dans cette case. À notre surprise, nous ne pouvons pas en créer beaucoup. Essentiellement, la taille minimale de la pile que vous pouvez définir avec -xss est de 64k. Les mathématiques simples vous diront que 64 * 7000 consommeront 430 Mo afin de pouvoir atteindre environ 7 000 threads environ, puis nous avons rencontré cette erreur:
java.lang.OutOfMemoryError: unable to create new native thread.
6 Réponses :
Ce n'est pas le langage de programmation, c'est sur le niveau du système d'exploitation.
Plus de lecture à ce sujet, pour Windows:
Dans le cas de cette personne, ils frappent une limite de mémoire avant de ne jamais toucher la limite du noyau.
@Jason - En effet, j'ai raté le "OutofMemoryError" sur le chemin.
Je crois que "OutofMemoryError: Impossible de créer un nouveau fil natif" peut être causé par la limite de filetage par traitement du système d'exploitation, malgré une exception exceptionnelle. Pas sûr à 100% sur cela cependant.
En fait, @ConLind a raison, les limites de processus apparaissent également comme une erreur de mémoire.
Gardez à l'esprit que vous ne serez jamais capable de consacrer à 100% de la RAM pour exécuter des fils Java. Certaines RAM sont utilisées par le système d'exploitation et d'autres applications en cours d'exécution, ce qui signifie que vous n'aurez jamais la totalité de 512 Mo disponible.
Essayez de régler la mémoire maximale autorisée -xmx à une valeur inférieure et voir si le nombre de threads peut être augmenté. Dans un projet au travail, je pourrais affecter environ 2,5k threads avec -xmx512m et environ 4K threads avec -xmx96m.
Le plus grand votre tas le plus petit votre espace de pile de fil (au moins à mon expérience).
Une fois que vous avez créé vos fils de 7k, vous n'aurez aucune mémoire pour faire quoi que ce soit utile. Peut-être devriez-vous avoir une reproduction à la conception de votre application?
Quoi qu'il en soit, n'est pas 512 Mo assez petit? Peut-être que vous pourriez fournir un peu plus d'informations sur votre application ou peut-être le domaine?
Utilisez l'IO asynchrone (Java Nio) et vous n'avez pas besoin de 7k threads pour prendre en charge les clients de 7k, quelques filets pour la manipulation IO (5?) suffiront.
Jetez un coup d'œil à Netty ;)
Un thread pour chaque client est un design vraiment mauvais.
Y a-t-il encore une limite sur le nombre de fils Nio? Je m'occupe d'une bibliothèque tierte partie qui semble créer des milliers de fils, il utilise Nio Tho ... semble causer la même erreur décrite par OP ...
Vous n'avez pas nécessairement besoin d'un fil par session client. Si vous regardez la manière dont un serveur J2EE (ou Javaee) gère plusieurs connexions, il utilise un mélange de stratégies, y compris la concurrence, la queue et l'échange. Habituellement, vous pouvez configurer le nombre maximal d'instances concurrentes en direct et de valeurs de délai d'inactivité au moment du déploiement pour régler la performance de votre application.
Avez-vous vraiment besoin de beaucoup de discussions? Combien de processeurs / cœurs la machine a-t-il?
Nous prévoyons de soutenir de nombreux clients. Il est hébergé sur un nuage virtuel alors pas sûr.
Si vous avez besoin de 7 000 threads natifs, vous avez une faille de conception sérieuse dans votre application.
Pourquoi? Nous construisons un serveur avec beaucoup de connexions réseau persistantes entrantes
@erotsppa - et c'est pourquoi vous créez des pools de connexion.
@erotsppa: Multiplex L'IO, ne créez pas uniquement des fils non liés ou repensez votre conception de protocole et préférez les connexions non persistantes.
Peut-être que vous pourriez expliquer ce que vous essayez de faire et une conception différente pourrait être suggérée?
Ce nombre de threads sera un goulot d'étranglement. Les commutateurs contextuels entre les threads seront terribles.