FRC - Event Dispatching Thread (一)
不論何時，當我們執行一個Swing應用程式時，會有3個Thread自動被建立...
- main thread
- toolkit thread
- EDT
首先第一個是用來執行應用程式中的main()方法，第2個是用來監聽系統事件，像是鍵盤的輸入 or 滑鼠的移動....等等諸如此類的事件。
而取得的事件會被送到Event Dispatching Thread(以下簡稱為EDT)上面 ，也就是第3個thread。
EDT，它重要性中的其中一點就是處理元件的繪製，它透過 toolkit thread控制著事件的取得，然後分派給適當的元件，並且通知元件重繪（在適當的時候）。
例如：
如果我們在JTextFiled上面按下一個按鍵，EDT會分配這個事件到此元件的key listener，並送一個重繪要求（paint request）到事件佇列（event queue）上，之後EDT會將paint request從event queue上取出，並通知元件重繪它自己。
簡單的來說...
每件在AWT、Swing(元件)上所發生的事都在EDT上。
不過要注意的是，如果事件收到的比送出的快，EDT將會讓它們（指的是未送出的事件）排隊等待，直到可以被處理為止。
另外在EDT上執行長時間的操作，像是讀 or 寫一個大的檔案，將會block所有的UI。一旦進行著長時間的操作，這個時候將沒有事件會被分派而且螢幕不會更新。看起來就好像是停止的，或是很慢的，也就是類似deallock的情況發生。
下面的程式是一個簡單的Demo，用來表達在EDT中讀 or 寫一個大的檔案的情況 XD
很明顯的，在操作費時任務時，button因為等待而重繪失敗，直到任務處理完時，才有機會重繪。其實不只有button，而是整個Swing都在等待著這個任務結束，所以當我們在這期間去縮放Swing一樣會有凍結的情況發生，也不會對任何事件做出回應。
