Java: Threading Techniques & amp; concetti

Question

Quando utilizzo i thread, a volte li visualizzo come intrecci di 3 o più interconnessioni dimensionali tra Oggetti in un contesto spaziale. Questo non è uno scenario d'uso generale, ma per quello che faccio è un modo utile di pensarci.

Ci sono API che usi per agevolare il threading?

Hai usato i thread in un modo che non concettualizza come thread sia un processo?

Answer 1

Esistono API che usi per agevolare il threading?

Intendi appart da java.util.concurrent ? FunctionalJava ha ottenuto alcuni costrutti che aiutano nella programmazione concorrente, come descritto in un tutorial multipart che inizia qui .

Hai usato i thread in un modo che non concettualizza come thread sia un processo?

Sì, nella misura in cui i thread non concettualizzano affatto. Prendi ad esempio un task-runner asincrono. Usa i fili sotto le copertine ma non li vedo e non mi interessa. Sono completamente gestiti dal task runner.

Sotto le copertine, è tutto solo thread, ma quando smettiamo di preoccuparci del singolo thread e pensiamo a loro come a un numero di slot in cui puoi in qualche modo inserire il codice e farlo funzionare per un periodo di tempo, quindi questo è quando iniziamo a raggiungere un livello più alto di astrazione.

Agenti / Attori è un modo comune per farlo. Un attore è come un thread che ha un grumo di stato, quindi puoi inviargli del codice e dire "fallo al tuo stato quando hai tempo" o qualcosa del genere.

Answer 2

Prima di tutto

Il solito disclaimer: la programmazione concorrente, in qualsiasi lingua, usando qualsiasi livello di astrazione, è difficile e complicata e presenta molti rischi. Prendi in considerazione:

• La programmazione concorrente complica qualsiasi applicazione per grandezza
• Le sezioni critiche di unit test sono difficili e talvolta impossibili
• La riproduzione di bug che hanno origine in codice simultaneo è molto difficile e dipende molto dall'architettura, dal sapore del sistema operativo, dalla versione, ecc ...

API simultanee Java

Java ha fatto molto per rendere la programmazione simultanea il più semplice possibile per gli sviluppatori. Nella maggior parte dei casi, vedrai che java.util.concurrent ha la maggior parte delle astrazioni necessarie:

Interfaccia
• Runnable e Thread che puoi estendere. Inserisci il tuo codice e hai un thread pronto per essere eseguito
• Un bel set di Executors : pool costante, pool dinamico, pianificato o altro. Basta lanciare un Runnable e fa il resto.
• Semaphore s e blocchi di ogni sorta ti sollevano dalla necessità di implementare tecniche di blocco comuni.
• Un'API wait () e Notify () integrata per tutti gli oggetti.

Utilizza

L'unica cosa rimasta per te, come ingegnere del software, è assicurarti di scrivere il codice corretto . Significa che dovresti essere consapevole delle situazioni pericolose a cui potresti essere esposto:

• Deadlock : una situazione in cui due o più thread sono in attesa di risorse non ordinate, creando un ciclo di attesa infinito.
• Livelock - due o più thread che educatamente cercano di cedere il passo all'altro su una risorsa condivisa ma finiscono per non prenderlo (considera due persone in un corridoio che si avvicinano e si muovono costantemente) insieme da un lato all'altro)
• Fame : un singolo thread occupa la maggior parte o la totalità di una singola risorsa condivisa, privando così altri thread dall'accesso ad essa.

Punto principale (o, quando usare)

Utilizza i thread solo quando la concorrenza migliorerà direttamente il comportamento delle tue applicazioni.

Se stai aspettando una risorsa legata a IO / rete / hardware, DO genera un thread su di esso in modo da poter continuare a fare altre cose.

Se stai solo cercando di dividere in modo elegante i calcoli associati alla CPU, NON usa i thread. Potresti semplicemente peggiorare la tua esibizione.

Se usi i thread, assicurati di aver attentamente studiato i rischi e di aver verificato tre volte che non hai perso nessuna situazione eccezionale.

Risorse utili (online)

Il modo più veloce per entrare nelle cose è fare il Tutorial sulla concorrenza di Sun . A parte questo, prendi un buon libro.

Buona fortuna :)

Answer 3

La concorrenza è un argomento profondo e complicato da trattare. Libri come Java Concurrency in Practice possono aiutare.

Vedi Panoramica sulle utility di concorrenza per API sul threading. BlockingQueue < E > può essere utile ad esempio.

  

Una coda che supporta ulteriormente   operazioni che attendono la coda   diventa non vuoto quando si recupera un   elemento e attendere che lo spazio diventi   disponibile nella coda quando si memorizza un   elemento.

Vedi CountDownLatch

  

Un aiuto di sincronizzazione che lo consente   o più thread in attesa di un set di   operazioni eseguite in altro   discussioni completate.

e CyclicBarrier per alcuni comportamenti interessanti.

  

Un aiuto di sincronizzazione che consente a   insieme di thread per tutti aspettare per ciascuno   altro per raggiungere un punto di sbarramento comune.

Modifica : Sto leggendo Java Concurrency in Practice ora. È molto buono.

Answer 4

  

Quando utilizzo i thread, a volte li visualizzo come intrecci di 3 o più interconnessioni dimensionali tra gli oggetti in un contesto spaziale.

Sembra complicato, come ad esempio concettualizzi 600 thread? Perché non pensarli come più thread di esecuzione eseguiti apparentemente contemporaneamente.

  

Esistono API che usi per agevolare il threading?

Suggerisco che le prime partite che troverai siano le più semplici e dirette. http://www.google.co.uk/search?q=java+ fili

  

Hai usato i thread in un modo che non concettualizza come thread sia un processo?

Dato che i thread non sono processi, non posso dire di aver mai pensato ai thread come a processi. (Tranne che nelle vecchie versioni di Linux) I processi non condividono la memoria / gli oggetti per impostazione predefinita per un avvio, ma vengono eseguiti in modo completamente indipendente (in genere programmi diversi, possibilmente scritti in lingue diverse). Inoltre, si avviano in modo diverso utilizzando API diverse.

È opinione che il multi-threading sia complicato. In realtà direi il contrario. La programmazione multi-thread richiede che tu renda il tuo codice semplice, facile da capire e diretto al ragionamento. Mentre ciò richiede esperienza, il tuo obiettivo è la semplicità.