Combien de threads une VM Java peut-elle supporter ?

Question

Combien de threads une VM Java peut-elle supporter ? Cela varie-t-il selon le fournisseur, le système d'exploitation ou d'autres facteurs ?

Answer 1

Cela dépend du processeur que vous utilisez, du système d'exploitation, de ce que font les autres processus, de la version de Java que vous utilisez et d'autres facteurs. J'ai vu un serveur Windows avoir > 6500 threads avant de mettre la machine hors service. La plupart des threads ne faisaient rien, bien sûr. Une fois que la machine a atteint environ 6500 Threads (en Java), toute la machine a commencé à avoir des problèmes et à devenir instable.

D'après mon expérience, Java (versions récentes) peut consommer sans problème autant de threads que l'ordinateur lui-même peut en accueillir.

Bien sûr, vous devez disposer de suffisamment de RAM et vous devez lancer Java avec suffisamment de mémoire pour faire tout ce que les Threads font et pour avoir une pile pour chaque Thread. Toute machine équipée d'un processeur moderne (les deux dernières générations d'AMD ou d'Intel) et disposant de 1 à 2 gigaoctets de mémoire (selon le système d'exploitation) peut facilement prendre en charge une JVM avec milliers de fils.

Si vous avez besoin d'une réponse plus spécifique que celle-ci, votre meilleure chance est de faire un profil.

Answer 2

Um, beaucoup.

Il y a plusieurs paramètres ici. La VM spécifique, ainsi que des paramètres d'exécution sur la VM. Cela dépend en partie du système d'exploitation : quelle est la prise en charge des threads par le système d'exploitation sous-jacent et quelles sont les limites qu'il leur impose ? Si la VM utilise effectivement des threads au niveau du système d'exploitation, le bon vieux truc du thread rouge/du thread vert.

Ce que signifie "support" est une autre question. Si vous écrivez un programme Java qui est juste quelque chose comme

   class DieLikeADog {
         public static void main(String[] argv){
             for(;;){
                new Thread(new SomeRunaable).start();
             }
         }
    }

(et ne vous plaignez pas des petits détails de syntaxe, je n'en suis qu'à ma première tasse de café), vous devez certainement vous attendre à faire tourner des centaines ou des milliers de threads. Mais créer un Thread est relativement coûteux, et la surcharge de l'ordonnanceur peut devenir intense ; il n'est pas évident que vous puissiez faire faire quoi que ce soit d'utile à ces threads.

Mise à jour

Ok, je n'ai pas pu résister. Voici mon petit programme d'essai, avec quelques embellissements :

public class DieLikeADog {
    private static Object s = new Object();
    private static int count = 0;
    public static void main(String[] argv){
        for(;;){
            new Thread(new Runnable(){
                    public void run(){
                        synchronized(s){
                            count += 1;
                            System.err.println("New thread #"+count);
                        }
                        for(;;){
                            try {
                                Thread.sleep(1000);
                            } catch (Exception e){
                                System.err.println(e);
                            }
                        }
                    }
                }).start();
        }
    }
}

Sur OS/X 10.5.6 sur Intel, et Java 6 5 (voir commentaires), voici ce que j'ai obtenu

New thread #2547
New thread #2548
New thread #2549
Can't create thread: 5
New thread #2550
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:592)
        at DieLikeADog.main(DieLikeADog.java:6)

Answer 3

Après avoir lu le billet de Charlie Martin, j'étais curieux de savoir si la taille du tas faisait une différence dans le nombre de threads que vous pouvez créer, et j'ai été totalement abasourdi par le résultat.

En utilisant le JDK 1.6.0_11 sur Vista Home Premium SP1, j'ai exécuté l'application de test de Charlie avec différentes tailles de tas, entre 2 Mo et 1024 Mo.

Par exemple, pour créer un tas de 2 Mo, j'invoquerais la JVM avec les arguments -Xms2m -Xmx2m.

Voici mes résultats :

2 mb --> 5744 threads
4 mb --> 5743 threads
8 mb --> 5735 threads
12 mb --> 5724 threads
16 mb --> 5712 threads
24 mb --> 5687 threads
32 mb --> 5662 threads
48 mb --> 5610 threads
64 mb --> 5561 threads
96 mb --> 5457 threads
128 mb --> 5357 threads
192 mb --> 5190 threads
256 mb --> 5014 threads
384 mb --> 4606 threads
512 mb --> 4202 threads
768 mb --> 3388 threads
1024 mb --> 2583 threads

Donc, oui, la taille du tas a vraiment de l'importance. Mais la relation entre la taille du tas et le nombre maximum de fils est INVERSEMENT proportionnelle.

Ce qui est bizarre.

Answer 4

Je sais que cette question est assez ancienne mais je veux juste partager mes découvertes.

Mon ordinateur portable est capable de gérer le programme qui génère 25,000 threads et tous ces threads écrivent des données dans la base de données MySql à intervalles réguliers de 2 secondes.

J'ai exécuté ce programme avec 10,000 threads pour 30 minutes continuously Ensuite, mon système était également stable et j'ai pu effectuer d'autres opérations normales comme la navigation, l'ouverture et la fermeture d'autres programmes, etc.

Avec 25,000 threads système slows down mais il reste réactif.

Avec 50,000 threads système stopped responding instantanément et j'ai dû redémarrer mon système manuellement.

Les détails de mon système sont les suivants :

Processor : Intel core 2 duo 2.13 GHz
RAM : 4GB
OS : Windows 7 Home Premium
JDK Version : 1.6

Avant l'exécution, j'ai défini l'argument jvm -Xmx2048m .

J'espère que cela vous aidera.

Answer 5

El maximum théorique absolu est généralement le espace d'adressage utilisateur divisé par la taille de la pile de threads (bien qu'en réalité, si toute votre mémoire est réservée aux piles de threads, vous n'aurez pas de programme fonctionnel...).

Ainsi, sous Windows 32 bits, par exemple, où chaque processus dispose d'un espace d'adressage utilisateur de 2 Go, ce qui donne à chaque thread une taille de pile de 128 Ko, on peut s'attendre à un maximum absolu de 16384 threads (=2*1024*1024 / 128). En pratique, je trouve que je peux en démarrer environ 13 000 sous XP.

Alors, je pense que vous êtes essentiellement dans la question de savoir si (a) usted peut gérer le fait de jongler avec autant de threads dans votre code sans faire de choses manifestement stupides (comme les faire tous attendre sur le même objet puis appeler notifyAll()...), et (b) si le système d'exploitation le peut. En principe, la réponse à (b) est "oui" si la réponse à (a) est également "oui".

Par ailleurs, vous pouvez spécifier la taille de la pile dans le constructeur du Thread Vous n'avez pas besoin (et ne devriez probablement pas) de vous embêter avec les paramètres VM pour cela.