Perché la maggior parte della logica dovrebbe essere negli oggetti monitor e non negli oggetti thread quando si scrive software concorrente in Java?

Ti sta facendo fare del multithreading davvero elementare. O forse potresti chiamarlo single-threading. Se tutto è nella classe Monitor e ogni metodo è sincronizzato, non è possibile accedere a più di un thread alla volta. Questo rinuncia alla maggior parte dei vantaggi del codice multithread e non è adatto a insegnarti molto. D'altra parte, il programma è adatto a lavorare, aumentando così la fiducia negli studenti. È senza dubbio un buon punto di partenza.

Il multithreading hard core significa molti thread che accedono agli stessi campi nello stesso momento. Mantiene tutti i core del tuo computer occupati e così il lavoro viene svolto più rapidamente. Ma è follemente ingannevole, generando un sacco di bug irrisolvibili. Penso che il tuo docente stia cercando di farti entrare lentamente. (E probabilmente sta cercando di salvarsi un po 'di lavoro aiutando gli studenti i cui programmi hanno bug estremamente sottili e anche che gli studenti finiscano tutti i loro compiti entro la fine del semestre.)

Non sono sicuro di cosa dire del tuo docente.

Non c'è quasi mai alcun motivo per estendere Thread. La solita pratica in Java è quella di implementare Runnable. Questo Runnable viene quindi passato a un thread oa un pool di thread, che eseguono il lavoro specificato in run (). Pensa al corpo del metodo run () come a un'unità di lavoro che deve essere eseguita da un thread.

Mettere la logica in un oggetto singleton con metodi sincronizzati .... questo non ha assolutamente senso ed è un pessimo design. Chiamare un metodo sincronizzato blocca l'oggetto circostante, il che significa che ogni thread che chiama i metodi sincronizzati su quell'oggetto blocca tutti gli altri thread, anche se chiamano metodi sincronizzati diversi. Se la tua intera simulazione viene eseguita attraverso una classe "Monitor" singleton, tutti i thread dovranno bloccare tutti gli altri thread ogni volta che chiamano uno dei metodi. Questo è orribile per le prestazioni ed è un ottimo modo per creare deadlock se hai più di una classe come questa nel tuo programma. L'intero approccio è un enorme vaso di vermi.

Un programma multi-thread correttamente progettato avrà generalmente una serie di Runnables che rappresentano le unità di lavoro. Alcune classi genereranno questi Runnable e li daranno ad un pool di thread che li eseguiranno. Se questi Runnables non condividono le risorse, non è necessario afferrare i blocchi. Se Runnables sta condividendo le risorse, si individua un modo per rappresentare tali risorse con un oggetto di blocco e distribuire tali oggetti di blocco ai Runnables in modo che possano sincronizzarsi su di essi durante il metodo run ().

L'obiettivo è far sì che i thread si blocchino l'un l'altro nella misura minima possibile. Questo è l'esatto opposto del modello fornito dal tuo istruttore.