2012-05-08 10 views
7

Attualmente sto imparando gli attori in Scala. Il libro consiglia di utilizzare il metodo react anziché receive, perché consente al sistema di utilizzare meno thread.Ha molti thread in un'applicazione JVM costosi?

Ho letto why creating a thread is expensive. Ma quali sono i motivi per cui, una volta ottenuti i thread (che dovrebbero essere validi per il sistema degli attori in Scala dopo l'inizializzazione), averli in giro è costoso?

È principalmente il consumo di memoria? O ci sono altri motivi?

+0

Si noti che questa domanda riguarda il sovraccarico di thread * dopo * la creazione, quindi non è un duplicato della domanda collegata. Che in realtà è già indicato nella domanda ... – rolve

risposta

10

Utilizzando molte discussioni può essere più costosi di quelli che ci si aspetta, perché:

  • ogni thread consuma memoria al di fuori del mucchio che pone restrizioni su quante discussioni possono essere creati a tutti per JVM;
  • passa da un thread a un altro consuma un po 'di tempo della CPU, quindi se si dispone di attività che può essere eseguita in un singolo thread, si risparmiano i cicli della CPU;
  • c'è lo schedulatore JVM che ha più lavoro da fare se ci sono più thread. Lo stesso vale per lo scheduler del SO sottostante;
  • infine, ha poco senso utilizzare più thread di quanti siano i core della CPU per le attività associate alla CPU e ha poco senso utilizzare più thread I/O di quelli che si hanno attività I/O (ad esempio, client di rete).
+4

potrebbe valere la pena notare che il commento del "programmatore JVM" implica che le pause del GC saranno un po 'aumentate (poiché ci vuole più tempo per portare tutti i thread su un safepoint), probabilmente più evidente su giovani gen pause – Matt

+0

@Matt che bel punto! Grazie! –

2

Oltre al sovraccarico della memoria di avere un thread in giro (che può essere o non essere piccolo), avere più thread in giro significherà anche che il programma avrà più elementi da considerare quando arriverà il momento di scegliere quale thread otterrà la CPU successiva.

Alcuni sistemi operativi/JVM possono anche avere vincoli sulla quantità di thread che possono esistere contemporaneamente.

Alla fine, si tratta di un accumulo di piccoli costi generali che possono eventualmente contribuire molto. E niente di tutto questo è specifico di Java.

2

Avere discussioni in giro non è "costoso". Certo, dipende da quanti di questi stiamo parlando. Sospetto che miliardi di thread sarebbero un problema. Penso che in generale, avere un sacco di thread è considerato costoso perché puoi fare più lavoro parallelo così la CPU sale, la memoria sale, ecc ... Ma se sono gestiti correttamente (raggruppati ad esempio per proteggere le risorse di sistema) allora va bene. La JVM non utilizza necessariamente i thread nativi, quindi un thread Java non è necessariamente mappato a un thread nativo del sistema operativo (ad esempio, ad esempio, i thread verdi o i thread leggeri). A mio parere, non vi è alcun costo implicito per i thread nella JVM. Il costo deriva da una cattiva gestione dei thread e da un uso eccessivo delle risorse assegnando loro incautamente lavoro.

+1

Questa è la migliore spiegazione finora, quindi +1. –

+0

Certo che è "costoso". Usa la memoria. Credo che il valore predefinito sia 1MB/thread sulla macchina a 64 bit. Quindi 1000 thread => 1 GB. Puoi avere 32 GB e non preoccuparti, ma "non costoso" è fuorviante. –

Problemi correlati