Passando singolo oggetto eseguibile a più costruttori filo

Question

Se creo un oggetto eseguibile

Runnable run = new MyRunnable(); 

e quindi passare lo stesso oggetto esatta fino a due costruttori di thread e li gestiscono

new Thread(run).start; 
new Thread(run).start; 

1. è il possibile ? Quali sono le implicazioni?
2. Se chiamo Thread.sleep (0); in classe MyRunnable, entrambi i thread dormiranno perché sono lo stesso oggetto oppure l'entità thread è completamente separata dall'oggetto?
3. Ci sarebbe mai una ragione per farlo, se non si prega di rispondere comunque alle due domande precedenti, perché non penso di aver capito completamente il meccanismo del thread ancora?

Answer 1

1. E 'sicuramente possibile e legale. Se il tuo non ha uno stato (nessun campo), allora tutto andrà bene. Se lo Runnable ha uno stato mutabile, potrebbe essere necessario utilizzare uno dei molti meccanismi di esclusione reciproca di Java come ReentrantLock o la parola chiave synchronized. Poiché entrambi i thread modificheranno i campi dello stesso oggetto Runnable.

2. No, hai creato e eseguito due thread diversi. Chiamano semplicemente Runnable.run().

3. Non è fuori dal regno delle possibilità. Non direi nemmeno che è necessariamente una cattiva pratica. situazioni specifiche in cui si potrebbe fare questo lasciato come esercizio per il lettore ...

Answer 2

1) è il possibile? Quali sono le implicazioni?

Sì, è possibile.

L'implicazione è che qualsiasi stato nel Runnable è (potenzialmente) condiviso da tutti i thread e l'accesso a/update di tale stato deve essere correttamente sincronizzato.

2) Se chiamo Thread.sleep (0); in classe MyRunnable, entrambi i thread dormiranno perché sono lo stesso oggetto oppure l'entità thread è completamente separata dall'oggetto?

No, non lo faranno.

La discussione è logicamente distinta dallo Runnable. La chiamata a Thread.sleep() non influisce direttamente sullo e su altri thread che potrebbero condividerla. (Si potrebbe effettuare altri fili indirettamente, ad esempio se un thread dorme mentre sta tenendo lock primitivo del Runnable, e gli altri thread devono acquisire il blocco di progredire.)

3) Sarebbe mai esserci una ragione per fare questo, se no, per favore rispondi comunque alle due domande precedenti, perché non credo di aver capito completamente il meccanismo del thread?

È forza farlo se non c'è uno stato-specific thread associato con la Runnable e di voler ridurre al minimo le spese generali dello spazio, o le spese generali di inizializzazione del Runnable. Ma tali casi d'uso sono rari nella pratica.

Nella maggior parte dei casi di utilizzo del mondo reale, ogni thread richiede un'istanza distinta Runnable.