Quando usare SwingUtilies.invokeAndWait/invokeLater

Question

ho letto da qualche parte che per tutti i thread che colpisce le immagini della GUI che dovrebbe essere eseguito nella EDT utilizzando SwingUtilities.invokeAndWait/invokeLater

Per una GUI di base, è necessario per inserire qualcosa come new SwingGUI().setVisible(true); nella riga di EDT usando invokeAndWait? Solo per visualizzare?

Conta questo?

Answer 1

Sì, se si tocca un oggetto Swing, è necessario farlo sull'EDT. Nella maggior parte dei casi sei già lì, ma in caso contrario, utilizza le classi SwingUtilities. La ragione di ciò è che le classi Swing non sono multi-thread, quindi è probabile che si verifichino problemi fastidiosi se si accede ad altri thread. E potrebbe essere che setVisible() stia facendo un sacco di cose sotto le copertine per far visualizzare qualcosa (come ri-sistemare le cose). Meglio essere al sicuro.

Answer 2

La risposta breve alla tua domanda è: sì, anche chiamare setVisible dovrebbe avvenire sull'EDT. Per scoprire se il thread corrente è l'EDT, è possibile utilizzare il metodo EventQueue#isDispatchThread

Alcuni link di riferimento:

• Multithreaded Swing Applications
• Threads and Swing
• Concurrency in Swing

Edit: dopo leggendo i link che ho fornito, sembra che alcuni degli articoli sul sito Oracle siano obsoleti come nel loro documento ancora è possibile creare componenti Swing su un altro thread. C'è uno stackoverflow question su questo che contiene alcune belle risposte e link a blog e articoli sulla politica 'nuova' (nuovi come in pochi anni)

Answer 3

Tutto ciò che accede agli oggetti Swing dovrebbe farlo tramite il thread di invio eventi (EDT). C'è una piccola eccezione a questa (che menzionerò più avanti). Lo scopo di EDT è di elaborare qualsiasi evento che possa verificarsi a causa di eventi I/O (mouse e tastiera). Molto spesso questo può significare alterare il layout della tua GUI. Swing non è stato sviluppato per essere thread-safe, nel senso che se due thread tentano di modificare lo stesso componente nello stesso momento, si può finire con una GUI corrotta. Poiché esiste già un thread noto per accedere ai componenti di Swing (EDT), nessun altro thread dovrebbe tentare di modificarli o persino leggere il loro stato.

Ora, nel caso eccezionale in cui è possibile manipolare oggetti Swing al di fuori dell'EDT. Prima che tutti i componenti siano diventati visibili non è possibile che IO stia attivando eventi. Pertanto, il thread principale può configurare una GUI Swing e quindi impostare una singola JFrame per essere visibile. Poiché ora esiste un frame visibile, possono verificarsi eventi I/O e il thread principale non dovrebbe provare a modificare altri componenti Swing. Dovrebbe usare questa opzione solo per avviare una GUI, e in realtà solo con problemi di giocattoli.

Quello che sto dicendo è che quanto segue va bene e non causerà problemi se si sta solo giocando con roba del genere.

public static void main(String[] args) { 
    // create components 
    JFrame f = new JFrame(); 
    ... 

    // do layout and other bits of setup 


    // show gui to user 
    f.setVisible(true); 
} 

Answer 4

Tutto ciò che viene chiamato dal

public static void main(String[] agrs) { 

direttamente (senza deposizione delle uova un altro thread o utilizzando invokeLater) è in esecuzione sul thread principale.

L'accesso agli oggetti GUI con il thread principale mentre è possibile che si acceda (simultaneamente) dall'EDT (che viene attivato dall'input dell'utente) può causare problemi di threading. Chiamando invokeLater, le attività (eseguibili) vengono eseguite sull'EDT, impedendo l'accesso simultaneo da parte di altre attività EDT, ad es. pressioni dei pulsanti, ecc.

Se si è certi che EDT non è occupato (prima che la prima finestra sia impostata su SetVisible (true)) è possibile accedere alla GUI dal thread principale. Se si può essere sicuri che EDT non abbia alcun riferimento al componente su cui si sta lavorando (è fuori dall'ambito di EDT) vale a dire. prima di essere aggiunto a qualsiasi contenitore, è possibile accedervi dal thread principale senza che l'EDT lo acceda contemporaneamente, poiché l'EDT non ha modo di raggiungerlo.