2012-12-13 28 views
11

Sono piuttosto nuovo al multithreading e sto lavorando a un progetto in cui sto cercando di utilizzare 4 CPU nel mio programma Java. Volevo fare qualcosa comeJava - relazione tra thread e CPU

int numProcessors = Runtime.getRuntime().availableProcessors(); 
ExecutorService e = Executors.newFixedThreadPool(numProcessors); 

Sarà questa garanzia che avrò un thread di lavoro per CPU? Nel momento in cui creo i thread, il sistema non sarà occupato, tuttavia dopo qualche tempo sarà estremamente occupato. Ho pensato che il SO scegliesse la CPU meno occupata per creare i thread, ma come funziona se nessuno di questi è particolarmente occupato al momento della creazione?

Inoltre, il servizio del pool di thread dovrebbe riutilizzare i thread, ma se vede che c'è più disponibilità su un'altra CPU, ucciderà il thread e ne creerà uno nuovo lì?

+2

Il sistema operativo esegue la pianificazione dei thread, non Java. –

risposta

2

sarà questa garanzia che avrò un thread di lavoro per CPU?

Se si dispone di quattro attività che devono essere eseguite allo stesso tempo, è possibile aspettarsi che abbiano un thread ciascuna. Nella JVM HotSpot, crea l'oggetto Thread che è proxy per il thread attuale quando si crea il pool. Quando vengono creati i thread effettivi e in che modo è importante per te.

Nel momento in cui creo i thread, il sistema non sarà occupato, tuttavia dopo qualche tempo sarà estremamente occupato. Ho pensato che il SO scegliesse la CPU meno occupata per creare i thread, ma come funziona se nessuno di questi è particolarmente occupato al momento della creazione?

I thread vengono creati dal sistema operativo e vengono aggiunti all'elenco di thread da pianificare.

Inoltre, il servizio del pool di thread deve riutilizzare i thread, ma se vede che c'è più disponibilità su un'altra CPU, ucciderà il thread e ne creerà uno nuovo lì?

Java non ha voce in capitolo. Il sistema operativo decide. Non uccide e riavvia i thread.

I thread non sono collegati alle CPU nel modo suggerito. Il sistema operativo passa i thread tra le CPU in base a quali thread devono essere eseguiti e quali CPU sono libere.

+0

La mia preoccupazione è che il sistema operativo li istanzia tutti sulla stessa CPU e poi perché riutilizza i thread, che li manterrà lì, anche se arriva a un punto in cui la CPU è bloccata e gli altri 3 sono liberi . È possibile? – Marianna

+0

È possibile forzare il sistema operativo a farlo, ma per impostazione predefinita darà a ciascuna CPU, il prossimo thread libero che può essere eseguito. –

+0

Vedo, grazie per l'aggiornamento. Se il sistema operativo sta passando i thread tra le CPU, penso che risponda alla mia domanda. Qual è il modo migliore per monitorare questo su UNIX? Se uso la funzione 'top' vedrò più di un proc Java in esecuzione? – Marianna

2

no, non garantisce nulla in cui i fili corrono

infatti la pianificazione dei thread del sistema operativo è libero di migrare le discussioni intorno core come meglio ritiene opportuno (così una linea si potrebbe essere sul core 0 e la prossima sul core 4)

è possibile impostare la affinity di thread, ma questo non è disponibile in java direttamente (per quanto ne so)

1

"se vede che c'è più disponibilità su un'altra CPU, ucciderà il thread e ne creerà uno nuovo lì?"

Non è necessario uccidere e generare un altro per utilizzare la CPU disponibile. I thread sono oggetti di memoria che non sono legati a particolari CPU e possono spostarsi da una CPU all'altra.esecuzione filo è un ciclo come questo:

  • Thread.start() mette il filo nella coda del processore
  • quando c'è processore disponibile, scheduler prende il primo filo nella coda del processore un mette su processore
  • quando la blocchi di thread su un blocco occupato o in attesa della fine di un'operazione di I/O, viene rimosso dal processore e inserito nella coda corrispondente. Quando il blocco viene liberato o l'operazione di I/O termina, il thread viene spostato da quella coda alla coda del processore.
  • quando il thread funziona troppo a lungo senza bloccare (tempo dipendente da/s, ad esempio, 50 ms), si verifica un'interruzione e lo scheduler controlla se ci sono thread nella coda del processore. Se ci sono, il thread corrente viene rimosso dal processore e messo alla fine della coda del processore e il primo thread nella coda che mette sul processore. In questo modo il thread a lunga esecuzione consente anche agli altri thread di eseguire.

Come risultato, i thread spesso cambiano il loro stato ma questo è trasparente per il programmatore. L'intera idea dei thread è che thread è un modello di un processore, più conveniente del processore reale. Usa quel modello e non preoccuparti di mappare i thread sui processori, finché non ne hai davvero bisogno.

Problemi correlati