現代的gui框架使用了一個略微不同的模型：模型創建了一個專門的線程，事件派發線程（event dispatch thread，RDT）來處理gui事件。單線程化的GUI框架并不僅僅存在于java中：Qt、NextStep、Macos Cocoa、XWindows,等等都是單線程化的。也并不缺少反面的嘗試；有很多試圖寫出多線程的GUI框架的努力，最終都由于競爭條件和死鎖導致的穩定性問題，又回到了單線程化的事件隊列模型的老路上來：采用一個專門的線程從隊列中抽取事件，并把它們轉發給應用程序定義的事件處理器。（awt最初曾嘗試在某種程度上支持多線程訪問，單線程化地實現swing的決定主要基于AWT中的經驗和教訓。）多線程的GUI框架會尤其易受死鎖的影響，部分原因在于，輸入事件處理與任何GUI組件背后的對象模型之間存在偶發的交互。用戶發起的動作總會冒泡似的從操作系統傳遞給應用程序—先是由os檢測到一次鼠標點擊，然后工具集把它轉化為“鼠標點擊”事件，最終它會作為一個高層事件（比如“buttonpressed”事件）轉發給應用程序的監聽器。另一方面，應用程序發起的動作又會以冒泡的形式傳回操作系統—應用程序發起一個動作要改變某個組件的背景顏色，這會被轉發給一個特定的組件類，最終轉發給os進行渲染。兩種動作以完全相反的順序訪問相同的GUI對象，需要保證讓每一個對象都是線程安全的，這會導致一系列的鎖順序的不一致，這會直接引發死鎖。這個問題機會在每一次GUI工具集的開發中都會出現，是經驗之談。模型—視圖—控制器（mvc）模式的普遍流行形成了導致多線程GUI框架出現死鎖的另一原因。把用戶的互交分撥到模型、視圖和控制器之間的寫作中，極大地簡化了GUI應用程序的實現，但這讓不一致的鎖順序再次雪上加霜?？刂破髡{用模型，模型通知視圖已經發生了一些事情?？刂破魍瑯涌梢哉{用視圖，視圖可以依次回調模型來查詢模型的狀態。結果是，不一致的鎖順序再次伴隨死鎖的風險一同到來。Graham hamilton，sun公司的vp，在他的weblog中詳盡地概括了這些挑戰，描述了多線程GUI工具集之所以會成為計算機科學史上又一次“失敗的夢”。如果多線程GUI工具集經過非常謹慎的設計；如果工具集能使它加鎖的方法鮮明地顯露；如果你非常聰明，非常仔細，并且對工具集的整體框架有著全局的把握，我相信你還是可以成功地編寫出多線程的GUI來。但是如果這些事情有一些輕微的偏差，程序多數時候仍然運行良好，但是你會偶爾看到程序掛起或者運行故障。那些密切參與了工具集設計的人能夠很好地運用這種多線程方案。不幸的是，我認為這些特性并沒有和商業流行度成正比。一個中等能力的程序員，整日構建著被一些莫名其妙的原因困擾著而不能穩定運行的應用程序，我們很容易落入這種境界。于是應該程序的作者會倍感怨恨與失落，對無辜的工具集惡語相加。單線程化的GUI框架通過現場限制來達到現場安全性；所有GUI中的對象，包括可視組件和數據模型，都只是被事件線程訪問。當然，這只把線程安全負擔的一部分推給了應用程序的開發者，他們必須確保這些對象是被正確限制的。