Servlet線程池與EJB對象池
目前所有的B/S系統應用可以分爲：有狀態(statefull)和無狀態(stateless)兩大類別。 有狀態是指在整個系統的處理過程中要保留記住一些信息，而無狀態則相反，每次request都是獨立的連接，不需要在每個request之間共享數據等等。
對於這兩種應用，通常第一考慮是性能要最優，性能是我們選擇IT技術的主要依據之一。
爲達到最大化的性能，對於Java系統，以前通常的作法是使用對象池，這樣節約對象生成時的性能開銷，也就是說系統啓動時，預先生成一定數目的對象實例在內存中，需要使用時，從對象池中取出實例，用完，歸還對象池，對於有狀態的應用，可以使用相關持久化（persistence）策略來保存狀態。
下一步，如何並行訪問對象池將是非常重要，java的多線程技術爲我們提供了實現可能，線程的創建銷燬也是可能非常耗時的，那麼，無疑象使用對象池一樣，我們必須使用線程池來實現多線程並行計算的最優化。
使用線程池和對象池，每次客戶端請求發生一次就從線程池中借用一個線程，處理完這個請求就將線程返回線程池，同樣，使用線程快速的訪問對象，對象也是從對象池中借用，用完就還回對象池。 整個這樣的架構設計在性能上是最優的。
有了性能保證，安全機制、事務機制、集羣(cluster)技術也將是選擇IT技術的主要依據。
J2EE就是這樣一個實現上述多種考量的綜合標準框架系統，在具體使用中，也許我們對所有這些考量的要求並不都一樣重視，比如：如果純粹追求性能是第一，可以忽視事務機制，那麼，完整的J2EE技術也許就並不適合你。
那麼我們先看看J2EE是如何從性能上保證我們的應用系統以最快速度運行的，也就是說J2EE中必然應該有上述線程池和對象池的實現技術，servlet實際是基於線程池的更好的線程容器；EJB是基於對象池的更好的對象容器。
看看Servler的架構圖：
當client1發生請求時servlet容器會從線程池中分配一個線程給這個request.
再看看EJB的架構圖：
instance Pool作爲一個對象實例池，維持着EJB實例，當然這個對象池是用生命週期的，簡單的說 EJB=對象池+遠程對象池
但是，EJB還整合了相當的其它增強功能，如安全 事務機制等，這些對於一般應用都是必需的，當然你還必須根據你的需要來選擇是否使用J2EE，如果你的應用對安全 事務機制沒有要求，直接使用線程池和對象池技術肯定獲得最好的性能。
所以，根據Servler和EJB的原理，我們已經可以規劃我們的應用，什麼可以放在servlet，或什麼需要放在EJB中實現：
線程的本質決定了servlet只適合一些輕量的應用，如分析簡單XML文檔, 通過JDBC訪問數據源，使用JMS或JavaMail處理簡單的信息Message，或使用JTS/JTA處理簡單的事務機制，注意這些用詞都是"簡單"的，一旦複雜了，就要使用EJB了。
下面從客戶端和服務器端兩個方面來具體考量這兩個技術的使用，這裏的客戶端不一定是指最終客戶端，因爲J2EE是多層結構，中間層可能在多個服務器上實現，如果一個服務器上的服務是供另外一個服務器上的應用訪問的，那麼後者我們也稱爲客戶端。
根據應用的複雜程度和要求不同，分下列情況：
1.在WEB層可以實現的一些應用
如果你的系統沒有很複雜的事務處理，或訪問很多企業原有的資源，那麼可以藉助javabean這樣的一些Help性質的類來實現你的應用，但是，這樣的方案不是最乾淨clean, 最有效efficient, 或最有擴展性的scalable。
否則，將所有核心計算放置入EJB中。
2.所有的複雜商務計算核心都在EJB中完成
如果你的客戶端和服務器端之間有防火牆，那麼目前能夠無障礙通過防火牆的協議只有Http了(Web Service也是基於http就是這個道理)，既然使用http了，而Servlet是基於Http協議的，那麼就需要通過servlet來訪問EJB，這是我們最普遍的應用情況。
但是，如果你的客戶端和服務器端可以放置在一個網絡內，之間沒有防火牆，那麼就不必使用Servlet，直接使用Java調用RMI來訪問EJB，這樣性能是最好的，這時的Servlet大概只有用於控制Jsp的頁面的輸出了(MVC模式中的控制作用)。
如果是非java客戶端，可以通過CORBA組件來訪問EJB。
3.如果你的應用對速度要求很高，要求非常快，對於事務處理等方面幾乎無要求
直接使用J2SE，加上線程池和對象池技術，將會使你的java系統性能發揮極致。Jakarta.Apache.org有這兩種技術的源碼，線程池可以從Servlet容器Tomcat的源碼中發現。