Quante risorse non dormire e thread in attesa di consumare

Question

Mi chiedo, quanto costoso è quello di avere molti thread in stato di attesa in java 1.6 x64.

Per essere più specifici, sto scrivendo applicazione che funziona su molti computer e invia/riceve i dati da uno all'altro.Mi sento più comodo thread separato per ogni macchina collegata e attività, come 1) l'invio di dati, 2) la ricezione di dati, 3) a ristabilire la connessione quando non è caduto.Quindi, dato che ci sono N nodi in cluster, in ogni macchina si sta andando ad avere 3 fili per ciascuna delle N-1 vicini.In genere ci saranno 12 le macchine, che arriva al 33 comunicazione thread.

La maggior parte di quelli thread sarà dormire la maggior parte del tempo, quindi, per le finalità di ottimizzazione potrei ridurre il numero di thread e dare più lavoro a ciascuno di essi.Come, per esempio.ristabilire la connessione è la responsabilità di ricevere thread.O l'invio a tutti i computer connessi è fatto da un singolo thread.

Quindi non vi è alcun significativo perfomance impatto avere molti sonno thread?

Answer 1

Per la maggior parte dei casi, le risorse consumate da un sonno thread sarà il suo spazio di stack.Utilizzando un 2-fili per la connessione-modello, che credo sia simile a quello che stai descrivendo, è noto per causare grandi problemi di scalabilità, per questo motivo, quando il numero di connessioni crescere di grandi dimensioni.

Sono stato in questa situazione di me, e quando il numero di connessioni è cresciuto al di sopra di 500 connessioni (circa un migliaio di thread), si tende a ottenere in un sacco di casi in cui si ottiene OutOfMemoryError, in quanto i fili spazio di stack supera la quantità massima di memoria per un singolo processo.Almeno nel nostro caso, che è stato in Java su Windows a 32 bit mondo.È possibile ottimizzare le cose e ottenere un po ' di più, credo, ma alla fine non è molto scalabile, in quanto si spreca un sacco di memoria.

Se avete bisogno di un numero elevato di connessioni, Java NIO (nuovo IO o quello che è) è la strada da percorrere, rendendo possibile gestire un sacco di connessioni nello stesso thread.

Detto questo, non dovreste incontrare un gran problema, con meno di 100 thread su un ragionevolmente moderna server, anche se probabilmente è ancora uno spreco di risorse.

Answer 2

Abbiamo avuto molto lo stesso problema di prima siamo passati a NIO, quindi secondo Liedmans raccomandazione per andare con quel quadro.Si dovrebbe essere in grado di trovare un tutorial, ma se volete i dettagli, mi raccomando Java NIO da Ron Hitchens.

Swithcing a NIO aumentato il numero di connessioni che si potrebbe gestire un sacco, che è stato davvero fondamentale per noi.

Answer 3

Questo non scala molto bene.Avere un gran numero di thread significa che la VM deve spendere più tempo di context-switching e di memoria useage saranno più alte per ogni thread che richiedono il suo proprio spazio di stack.Si sarebbe meglio con un più piccolo numero di thread di elaborazione in una pipeline di moda, o utilizzare il pool di thread con asychronous tecniche.

Answer 4

Un sacco di thread che equivale a un sacco di spazio di stack, che si mangia la memoria - check-out your-Xss impostazioni per quanto, poi, fare i conti.

E se mai a fare un notifyAll() per qualche motivo, poi, ovviamente, si stanno svegliando carichi di fili in più - anche se potrebbe non essere necessario in architettura proposta.

Non sono sicuro che si può facilmente evitare di avere un thread per ogni socket in ascolto in questo modello (anche se non so molto di NIO - che potrebbe risolvere anche questo problema), ma date un'occhiata al java.util.simultanee.Esecutore interfaccia e l'implementazione delle classi per modo decente per evitare di avere troppi thread aggiuntivi appendere intorno.Infatti, il ThreadPoolExecutor potrebbe essere un buon modo per gestire il tuo thread di ascolto troppo, in modo da non spendere troppo tempo la creazione e la distruzione thread unneccessarily.

Answer 5

Dalle prove che ho fatto in C, Lua e Python, è possibile rendere il proprio sonno o la funzione di attesa con pochissime righe di codice per fare un leggero, semplice loop.Utilizzare una variabile locale con il tempo, in futuro, si vuole raggiungere e quindi di verificare che il timestamp corrente in un ciclo while.Se si è in un ambito in cui si lavora con fps, rendere l'attesa funzione di eseguire una volta per fotogramma per risparmiare risorse.Più di precisione è necessario, prendere in considerazione utilizzando il clock invece di timestamp, dal timestamp è limitata a pochi secondi.Il più righe di codice da aggiungere in una funzione di attesa, meno preciso, questo diventa più risorse che consuma, anche se nulla al di sotto dei 10 linee dovrebbe essere abbastanza veloce.