Quanti thread può supportare una Java VM?

Quanti thread può supportare una Java VM? Questo varia dal venditore? dal sistema operativo? altri fattori?

Questo dipende dalla CPU che stai usando, dal sistema operativo, da ciò che altri processi stanno facendo, da quale versione di Java stai usando e da altri fattori. Ho visto un server Windows avere> 6500 thread prima di mettere giù la macchina. La maggior parte dei thread non stava facendo nulla, ovviamente. Una volta che la macchina ha raggiunto circa 6500 thread (in Java), l’intera macchina ha iniziato a presentare problemi e diventare instabile.

La mia esperienza mostra che Java (versioni recenti) può consumare felicemente tante discussioni quante il computer stesso può ospitare senza problemi.

Certo, devi avere abbastanza RAM e devi aver avviato Java con abbastanza memoria per fare tutto ciò che sta facendo il thread e avere uno stack per ogni Thread. Qualsiasi macchina con una CPU moderna (la coppia più recente di AMD o Intel) e con 1 – 2 Gig di memoria (a seconda del sistema operativo) può facilmente supportare una JVM con migliaia di thread.

Se hai bisogno di una risposta più specifica di questa, la soluzione migliore è il profilo.

Ehm, molto.

Ci sono diversi parametri qui. La VM specifica, in più ci sono in genere anche i parametri di runtime sulla VM. Questo è in qualche modo guidato dal sistema operativo: quale supporto ha il sistema operativo sottostante per i thread e quali limitazioni comporta? Se la macchina virtuale utilizza effettivamente thread a livello di sistema operativo, il buon vecchio thread rosso / argomento filo verde.

Che cosa significa “supporto” è un’altra domanda. Se scrivi un programma Java è qualcosa di simile

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

(e non lamentarti dei piccoli dettagli sulla syntax, sono sulla mia prima tazza di caffè), quindi dovresti aspettarti di ottenere centinaia o migliaia di thread in esecuzione. Ma creare un Thread è relativamente costoso, e il sovraccarico del programmatore può diventare intenso; non è chiaro che potresti avere quei thread che fanno qualcosa di utile.

Aggiornare

Ok, non ho potuto resistere. Ecco il mio piccolo programma di test, con un paio di abbellimenti:

 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(); } } } 

Su OS / X 10.5.6 su Intel e Java 6 5 (vedi commenti), ecco cosa ho ottenuto

 Nuova discussione n. 2547
 Nuova discussione n. 2548
 Nuova discussione n. 2549
 Imansible creare il thread: 5
 Nuova discussione n. 2550
 Eccezione nel thread "main" java.lang.OutOfMemoryError: imansible creare un nuovo thread nativo
         a java.lang.Thread.start0 (metodo nativo)
         a java.lang.Thread.start (Thread.java:592)
         a DieLikeADog.main (DieLikeADog.java:6)

Dopo aver letto il post di Charlie Martin, ero curioso di sapere se la dimensione dell’heap potesse fare la differenza nel numero di thread che è ansible creare, e sono rimasto totalmente sbalordito dal risultato.

Usando JDK 1.6.0_11 su Vista Home Premium SP1, ho eseguito l’applicazione di test di Charlie con diverse dimensioni di heap, tra 2 MB e 1024 MB.

Ad esempio, per creare un heap di 2 MB, invocherei la JVM con gli argomenti -Xms2m -Xmx2m.

Ecco i miei risultati:

 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 

Quindi, sì, la dimensione dell’heap conta sicuramente. Ma la relazione tra la dimensione dell’heap e il numero massimo di thread è INVERSAMENTE proporzionale.

Che è strano

So che questa domanda è piuttosto vecchia ma voglio solo condividere le mie scoperte.

Il mio laptop è in grado di gestire un programma che genera 25,000 thread e tutti quei thread scrivono alcuni dati nel database MySql a intervalli regolari di 2 secondi.

Ho eseguito questo programma con 10,000 threads per 30 minutes continuously quindi anche il mio sistema era stabile e sono stato in grado di fare altre normali operazioni come la navigazione, l’apertura, la chiusura di altri programmi, ecc.

Con 25,000 threads sistema slows down ma rimane reattivo.

Con 50,000 threads sistema ha stopped responding all’istante e ho dovuto riavviare il mio sistema manualmente.

I dettagli del mio sistema sono i seguenti:

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

Prima di iniziare ho impostato l’argomento jvm -Xmx2048m .

Spero che sia d’aiuto.

Il massimo teorico assoluto è generalmente lo spazio degli indirizzi utente di un processo diviso per la dimensione dello stack di thread (anche se in realtà, se tutta la memoria è riservata agli stack di thread, non si avrà un programma funzionante …).

Quindi, in Windows a 32 bit, ad esempio, in cui ogni processo ha uno spazio di indirizzi utente di 2 GB, assegnando a ogni thread uno stack di 128 KB, ci si aspetterebbe un massimo assoluto di 16384 thread (= 2 * 1024 * 1024/128). In pratica, trovo che posso avviare circa 13.000 sotto XP.

Quindi, penso che tu sia essenzialmente nel decidere se (a) puoi gestire la giocoleria di molti thread nel tuo codice e non fare cose ovviamente stupide (come farli aspettare sullo stesso object e chiamare notifyAll () …), e (b) se il sistema operativo può. In linea di principio, la risposta a (b) è “sì” se la risposta a (a) è anche “sì”.

Per inciso, è ansible specificare la dimensione dello stack nel costruttore del Thread ; non è necessario (e probabilmente non dovrebbe) scherzare con i parametri VM per questo.

Ricordo di aver sentito un discorso Clojure in cui ha avuto modo di eseguire una delle sue app su una macchina specializzata in una fiera con migliaia di core (9000?), E li ha caricati tutti. Sfortunatamente, non riesco a trovare il link adesso (aiuto?).

Sulla base di ciò, penso che sia sicuro dire che l’hardware e il tuo codice sono i fattori limitanti, non la JVM.

Dopo aver giocato con la class di DieLikeACode di Charlie, sembra che la dimensione dello stack di thread Java sia una parte enorme di quanti thread è ansible creare.

-Xss imposta la dimensione dello stack del thread java

Per esempio

java -Xss100k DieLikeADog

Ma, Java ha l’interfaccia di Executor . Lo userò, sarai in grado di inviare migliaia di attività eseguibili e far sì che l’Esecutore esegua tali attività con un numero fisso di thread.

Se stai facendo questa domanda, potresti voler riscrivere il tuo codice.

Anno 2017 … Classe DieLikeADog.

Nuova discussione # 92459 Eccezione nel thread “main” java.lang.OutOfMemoryError: imansible creare un nuovo thread nativo

i7-7700 ram da 16 gb

Almeno su Mac OS X 10.6 32 bit, esiste un limite (2560) dal sistema operativo. Controlla questo thread di stackoverflow .

Il numero massimo di thread dipende dalle seguenti cose:

  • Configurazione hardware come microprocessore, RAM.
  • Sistema operativo come se sia a 32 o 64 bit
  • Codice all’interno del metodo di esecuzione. Se il codice all’interno del metodo run è enorme, l’object single thread avrà più requisiti di memoria
  • Informazioni aggiuntive per sistemi Linux (systemd) moderni.

    Ci sono molte risorse su questo dei valori che potrebbero richiedere modifiche (come ad esempio Come aumentare il numero massimo di thread JVM (Linux a 64 bit) ); tuttavia viene imposto un nuovo limite tramite il limite systemd “TasksMax” che imposta pids.max sul cgroup.

    Per le sessioni di login il valore predefinito di UserTasksMax è il 33% del limite del kernel pids_max (in genere 12,288) e può essere ignorato in /etc/systemd/logind.conf.

    Per i servizi il valore predefinito DefaultTasksMax è il 15% del limite del kernel pids_max (in genere 4.915). Puoi sovrascriverlo per il servizio impostando TasksMax in “systemctl edit” o aggiornare DefaultTasksMax in /etc/systemd/system.conf

    È ansible elaborare qualsiasi numero di thread; non c’è limite. Ho eseguito il seguente codice durante la visione di un film e l’utilizzo di NetBeans, e ha funzionato correttamente / senza arrestare la macchina. Penso che tu possa mantenere ancora più thread di questo programma.

     class A extends Thread { public void run() { System.out.println("**************started***************"); for(double i = 0.0; i < 500000000000000000.0; i++) { System.gc(); System.out.println(Thread.currentThread().getName()); } System.out.println("************************finished********************************"); } } public class Manager { public static void main(String[] args) { for(double j = 0.0; j < 50000000000.0; j++) { A a = new A(); a.start(); } } }