Безопасно ли создавать виджеты Swing / AWT НЕ в потоке отправки событий?

Question

Я интегрировал внешний вид Вещества в свое приложение и столкнулся с рядом проблем, связанных с его внутренними процедурами проверки EDT (Event Dispatch Thread). Вещество абсолютно отказывается строить классы пользовательского интерфейса за пределами EDT. Я сделал много Swing / AWT и знаю большинство правил, касающихся EDT. Я использую SwingWorker, SwingUtilties.invokeLater для изменения компонентов. Я всегда думал, что компоненты могут быть ПРОИЗВЕДЕНЫ вне EDT, но должны быть реализованы и манипулировать на EDT. Другими словами, вы можете создавать и устанавливать значения по умолчанию в фоновом режиме, но вызовом pack / setVisible должен быть EDT, а также любые последующие вызовы для управления компонентом.

Причина, по которой я спрашиваю, заключается в том, что у меня есть особенно «навороченное» окно для создания, включающее множество виджетов, состояний и ресурсов (много значков). Ранее я построил окно на фоновом методе SwingWorker и сделал окно видимым в готовом методе. Никогда не было ни одной проблемы. При переключении на Вещество внутренняя проверка EDT кусает меня.

Мне удалось изменить код, чтобы обойти это. Я могу построить на EDT, который не является хорошим решением, поскольку все приложение будет блокироваться. Я также могу реорганизовать еще больше и постараюсь загрузить все дополнительные ресурсы за пределами EDT.

Завершение ... Безопасно ли конструировать Swing / AWT виджеты НЕ в потоке отправки событий?

Answer 1

Sun изменила правила в 2004 году - раньше вам было разрешено создавать компоненты вне EDT, и вам нужно было перейти в EDT только после того, как компонент был реализован .

Новое правило теперь гласит:

Чтобы избежать возможности тупика, Вы должны быть очень осторожны, что Swing компоненты и модели созданы , изменен и запрашивается только из поток рассылки событий.

этот мой пост в блоге дает более подробную информацию, включая ссылки на другие связанные статьи. обратите внимание, что все официальные примеры Sun были переписаны и очень строги к этому.

Исторически сложилось так, что, вероятно, именно растущая доступность многоядерных компьютеров в качестве настольных компьютеров побудила переформулировать правило - проблемы многопоточности становились все более очевидными в клиентском стеке и очень строгими в отношении рекомендаций EDT. многие из них можно предотвратить с самого начала.

Answer 2

номер

Простая причина в том, что даже EDT любит блокировать блокировку в некоторых редких случаях, и вообще легко блокировать интерфейс пользователя при использовании Swing ( или около того, как мне сказали ). Я предлагаю вам прочитать эти три статьи из блога Кирилла (The Substance dev):

• Новая статья о нарушениях Swing EDT
• Неписанное правило работы с EDT Swing
• Более строгие проверки нарушений EDT в веществе