同步服務為每個請求創建單一線程，由此線程完成整個請求的處理：接收消息，處理消息，返回數據；這種情況下服務器資源對所有入棧請求開放，服務器資源被所有入棧請求競爭使用，如果入棧請求過多就會導致服務器資源耗盡宕機，或者導致競爭加劇，資源調度頻繁，服務器資源利用效率降低。
異步服務則可以分別設置兩個線程隊列，一個專門負責接收消息，另一個專門負責處理消息並返回數據，另有一些值守線程負責任務派發和超時監控等工作。在這種情況下無論入棧請求有多少，服務器始終依照自己的能力處理請求，服務器資源消耗始終在一個可控的范圍。這種模式的一個問題就是這兩個線程隊列的大小如何根據機器負載情況動態調整。
對於異步服務模式：
這種情況下，雖然入棧請求以消息隊列的方式被異步處理但每個請求內部卻是采用阻塞的方式訪問外部資源，如果外部資源訪問速度過慢，可能導致請求處理隊列中的所有線程均處於阻塞狀態，此時CPU使用率雖然很低但是卻因為隊列中線程已滿而無法處理消息隊列中的新消息，此時若能調整線程隊列最大線程數將可提高CPU利用率。但另一個問題是如果線程數被調高之后所有線程的IO處理突然結束並且接下來每個線程都將進行大量計算的話那么CPU可能出現過載。
在系統運行的每個時間點上，當時正在進行IO的線程數量和正在進行計算的線程數量是不斷變化着的，那么如何才能設計出一個可以根據系統當時情況自動適應負載變化的高度自適應的系統呢？
在這方面采用反應式計算模型確實能設計出適應負載能力很強的系統，系統利用率和吞吐量可以大幅提高，但這種系統仍然可能會出現系統局部負載過高的風險。
采用反應式計算模型，不僅系統中的入棧請求以消息隊列的方式得以異步化，而且系統中所有的IO任務也必需依照此法行之，這些IO任務的處理需要采用異步模型（如NIO）。另外要考慮的就是如何划分異步IO消息並為其配置線程隊列了，比如是要將所有IO任務放入統一的隊列還是為某類IO任務設置單獨的隊列。
服務器資源雖然由系統分配但大多以線程為持有者被線程持有並使用，如線程堆棧，被線程持有的各類鎖等資源。