通常，我們寫服務器處理模型的程序時，有以下幾種模型：
（1）每收到一個請求，創建一個新的進程，來處理該請求；
（2）每收到一個請求，創建一個新的線程，來處理該請求；
（3）每收到一個請求，放入一個事件列表，讓主進程通過非阻塞I/O方式來處理請求
分析：
第（1）中方法，由於創建新的進程的開銷比較大，所以，會導致服務器性能比較差,但實現比較簡單。
第（2）種方式，由於要涉及到線程的同步，有可能會面臨死鎖等問題。
第（3）種方式，在寫應用程序代碼時，邏輯比前面兩種都復雜。
綜合考慮各方面因素，一般普遍認為第（3）種方式是大多數網絡服務器采用的方式
在UI編程中，常常要對鼠標點擊進行相應，首先如何獲得鼠標點擊呢？
方式一：創建一個線程，該線程一直循環檢測是否有鼠標點擊，那么這個方式有以下幾個缺點：
1. CPU資源浪費，可能鼠標點擊的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描鼠標點擊的接口是阻塞的呢？
2. 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描鼠標點擊，還要掃描鍵盤是否按下，由於掃描鼠標時被堵塞了，那么可能永遠不會去掃描鍵盤；
3. 如果一個循環需要掃描的設備非常多，這又會引來響應時間的問題；
所以，該方式是非常不好的。
方式二：就是事件驅動模型
目前大部分的UI編程都是事件驅動模型，如很多UI平台都會提供onClick()事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下：
1. 有一個事件（消息）隊列；
2. 鼠標按下時，往這個隊列中增加一個點擊事件（消息）；
3. 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等；