Kann man Swing-Klassen in Nicht-EDT-Threads laden?

Question

Nach Einführung des Java-Speichermodells wurden die Swing-Richtlinien dahingehend geändert, dass alle Swing-Komponenten auf dem EDT instanziiert werden müssen, um einen nicht veröffentlichten Instanzstatus zu vermeiden.

Was ich nirgendwo finden konnte, ist, ob das Classloading auch auf dem EDT stehen soll oder können wir Key Swing-Klassen in einem Hintergrundthread vorladen? Gibt es dazu eine offizielle Stellungnahme von Sun/Oracle? Gibt es Klassen, von denen bekannt ist, dass sie einen nicht-threadsicheren statischen Zustand besitzen und daher auf EDT geladen werden müssen?

Klärung zu Nemis Frage zu beantworten: Dies ist ein praktisches Problem. Ein beträchtlicher Teil der Startzeit unserer Anwendung ist das Laden von Klassen und das Laden von Schriften/Bildern auf dem EDT. Das meiste davon kann Swing und verwandten Bibliotheken zugeschrieben werden.

Hier ist Som Hintergrund: Wie viele andere Swing-Anwendungen, sind wir beim Start vorkonfigurieren viele Formulare, um die Benutzeroberfläche reaktionsfähiger zu machen. Nach dem Profiling stellten wir fest, dass die tatsächliche Zeit für die Formularkonstruktion relativ schnell ist - was langsam ist, ist das Laden aller Klassen und Schriftarten (Festplattenlesevorgänge sind langsam im Firmen-Setup mit On-Access-Virenscanner, Überwachungsscanner, Überwachungs-Tracker und Gott weiß) was noch auf dem HDD-Treiber angeheftet wurde).

Wir haben versucht, die gleichen Formen in einem Hintergrund-Thread zu konstruieren (Swing-Regeln verletzen) und dann wegwerfen. Sobald wir fertig sind, konstruieren wir dieselben Formulare auf dem EDT, was viel schneller ist, wenn alle Klassen geladen sind und alle anderen Dateien im Plattencache sind. Es funktioniert für uns, und wir werden wahrscheinlich weitermachen, wenn nicht wirklich etwas Schlimmes passiert.

Was ich frage ist, ob dies eine sichere Praxis, eine gute Praxis oder ein Hack ist?

Answer 1

Die Beweise scheinen darauf hinzuweisen, dass es sicher ist - aber wiederum, wie ddimitrov in den Kommentaren sagt - die Chancen stehen dafür, keine subtilen Thread-Bugs aufgrund nicht veröffentlichter Änderungen zu finden, weil typische Maschinen nur wenige Kerne haben, und L2/L3-Caches werden gemeinsam genutzt. (L1-Caches sind pro Kern, aber in der Regel sehr klein.)

Wenn Sie sicherstellen wollen, dass kein Problem aufgrund der Hintergrund-Classloading entsteht, dann ist es wahrscheinlich am sichersten, auf Klassen auf der ETD zu bleiben. Um eine Live-Benutzeroberfläche zu verwalten, erstellen Sie einen benutzerdefinierten Klassenlader, der auch Ereignisse zwischen den einzelnen Klassen pumpt. (Abhängigkeiten werden direkt geladen, so dass die Verzögerung nur für die Dauer des Ladens von nur einer Klasse gilt.) Angenommen, dieser Klassenlader ist mit Ihrer Anwendung gepackt, kann er einfach alle Klassenladevorgänge auf seinen Klassenlader verschieben.

Alternativ können sekundäre Ereigniswarteschlangen verwendet werden, die auf separaten Threads ausgeführt werden (z. B. modale Dialoge und die Bibliothek spin). Das bedeutet, Swing kann auf jedem Thread laufen, solange es nur auf einem läuft, und bedeutet, dass es update-konsistent sein muss (oder dass wir alle bisher nur sehr viel Glück gehabt haben!). Auf der Grundlage davon könntest du Laden Sie Ihre Klassen auf den primären EDT und starten Sie einen sekundären EDT, um die UI-Ereignisse zu pumpen, und halten Sie die Benutzeroberfläche so ansprechend - so wie ein modaler Dialog funktioniert. Das Spin-Dienstprogramm pumpt EDT-Ereignisse für Sie oder Sie können einen neuen EDT von Hand erstellen.

• Spin
• Foxtrot

Answer 2

Obwohl Sie technisch korrekt sind - ich habe noch nie von einem Problem mit dem Rendern der Formulare in einem anderen Thread gehört, solange Sie nichts mit ihnen tun, sobald sie außer mit dem EDT realisiert werden ursprüngliche Richtlinien).

Früher waren die Richtlinien der Sonne, aber Sun änderte sie so, wie Sie angegeben haben - also bin ich mir sicher, dass jemand einen möglichen Konflikt gefunden oder geschaffen hat, aber ich bin mir auch sicher, dass es schwer werden wird arbeiten immer noch und fast keiner folgt diesen Richtlinien.

In Bezug auf Ihre Frage, ich bin sicher, dass Sie die Klassen laden können, solange Sie keine Objekte instanziieren und immer noch innerhalb der strengsten Richtlinien bleiben.

Der EDT wird nur verwendet, um Gewindekollisionen zu vermeiden, da Swing (vom Entwurf her) mit einem Gewinde versehen ist. Wenn Sie nur die Klassen laden und keine Instanzen erstellen, öffnen Sie sich nicht für Threading-Probleme.

Answer 3

Es ist sicher. Siehe: http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html (die Einfadenregel)

Wenn Sie Angst haben oder Feedback/Debuggen möchten, sehen Sie sich dieses FEST/Swing-Tool an: "Testen, dass der Zugriff auf GUI-Komponenten im EDT erfolgt") - Es ist eine benutzerdefinierte RepaintManager, die fehlschlägt, wenn Sie die EDT-Zugriffsrichtlinie verletzen.

Sie können diese hilfreich und finden: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

Sie das Laden von Klassen nicht explizit erwähnt, aber sie erklären, was die EDT-Richtlinie geht.