为何不使用事件分发线程会引发死锁？

我完全懂你的困惑——明明构造函数都跑完了，为啥调用text.setText()就卡壳了？而且pack()或者setVisible(true)随便一个就能触发死锁，这事儿确实反直觉，尤其是你本身就懂多线程，更想不通Swing为啥这么设计对吧？

咱们一步步拆解这个死锁的来龙去脉：

首先得明确Swing的核心铁律：所有Swing组件的创建、修改、查询操作，都必须在事件分发线程（EDT）上执行。这个规则不是凭空瞎定的——Swing组件本身不是线程安全的，EDT是专门用来处理所有UI相关逻辑的单线程，用这种单线程模型来保证UI状态的一致性，避免复杂的多线程锁竞争。

现在看你遇到的具体场景：

• 你在主线程（非EDT）里创建组件、调用add(text)，然后执行pack()或者setVisible(true)。这两个方法的底层会触发EDT的启动，而且它们会让主线程等待EDT完成一些关键的UI初始化工作——比如布局计算、组件的初始渲染。简单说，主线程此时会进入等待状态，等着EDT干完手里的活。
• 紧接着你在主线程里调用updateGui()，里面执行text.setText()。这个操作是要修改Swing组件的状态，而setText()内部逻辑要求必须在EDT上执行。但你现在是在主线程直接调用，这时候矛盾就来了：
  • 主线程正卡在pack()/setVisible(true)这里，等着EDT完成任务；
  • 而setText()因为不在EDT上执行，会尝试把这个修改请求提交给EDT，但EDT此时可能正在等待主线程释放某个内部锁（比如组件初始化时持有的锁），或者EDT本身也在等主线程先完成某个操作；
  • 这就形成了经典的死锁：主线程等EDT，EDT等主线程，双方都被卡住，谁都没法继续。

再说说你实验的结果：为什么把add(text)和updateGui()都用SwingUtilities.invokeLater()包起来就没事？

• 当你把这两个操作都放到EDT的任务队列里，主线程就不会直接持有组件的相关锁，也不会在调用pack()时和EDT产生锁竞争。pack()触发EDT启动后，EDT会依次执行队列里的add(text)、updateGui()任务，主线程只是提交完任务就继续走，不会傻等着EDT，自然就不会形成死锁。至于pack()达不到预期，是因为组件还没被EDT添加到窗口就执行了布局计算，结果肯定不对，但这是操作顺序的问题，和死锁无关。

最后再补充个细节：其实Swing有检测机制，如果你在非EDT线程操作组件，调试模式下会弹出警告。setText()内部会触发组件的属性变更和重绘请求，这些都必须由EDT处理，非EDT线程调用时，Swing会尝试把任务转交给EDT，但如果此时主线程已经在等EDT，就会出现循环等待的死锁。

说白了，Swing的单线程UI模型虽然限制多，但也是为了避免更复杂的线程安全问题——只是如果不遵守规则，就会出现这种看似诡异的死锁场景。

备注：内容来源于stack exchange，提问作者user29120650