Tomcat和Jetty作為Servlet引擎應用得比較廣泛，雖然Jetty成長為一個優秀的Servlet引擎，但是目前Tomcat的地位仍然難以撼動。相比較來看，他們都有各自的優、缺點。
Tomcat經過嘗試減的發展，已經廣泛的被市場接受和認可，相比Jetty來說，Tomcat比較穩定和成熟，尤其在企業級應用方面，Tomcat仍然是第一選擇。但是隨著Jetty的發展，Jetty的市場份額也在不斷提高，主要原因要歸功於Jetty的很多優點，而這些優點也是因為Jetty在技術上的優勢體現出來的。
架構比較
從架構上來說，顯然Jetty比Tomcat更加簡單。
Jetty的架構從前面的分析可知，他的所有組件都是基於Handler來實現的，當然他頁支持JMX。但是主要的功能擴展都可以用Handler來實現。可以說Jetty是面向Handler的架構，就像Spring是面向Bean的架構，iBATIS是面向Statement的一樣，而Tomcat是以多級容器構建起來的，他們的架構設計必然都有一個“元神”，所有以這個“元神”構建的其他組件都是肉身。
從設計模板角度來看，Handler的設計實際上就是一個責任鏈模式，接口類HandlerCollection可以幫助開發者構建一個鏈，而另一個接口類ScopeHandler可以幫助開發者控制這個鏈的訪問順序。另外一個用到的設計模板就是觀察者模式，用這個設計模式控制了整個Jetty的生命週期，只要繼承了LifeCycle接口，對象就可以交給Jetty來統一管理了。所以擴展Jetty非常簡單，也很容易讓人理解。整體架構上的簡單也帶來了無比的好處，Jetty可以很容易的被擴展和裁剪。
相比之下，Tomcat臃腫很多，Tomcat的整體設計很複雜，前面說了Tomcat的核心是他的容器的設計，從Server達到Service再到engine等container容器。作為一個應用服務器，這樣設計無可厚非，容器的分層設計也是為了更好的擴展，但是這種擴展的方式將應用服務器的內部結構暴露給外部使用者，使得如果想擴展Tomcat，開發人員必須要首先了解Tomcat的整體設計結構，然後才能知道如何按照他的而規範來做擴展。這樣就無形增加了對Tomcat的學習成本。不僅僅是容器，實際上Tomcat也有基於責任鏈的設計模式，像串聯Pipeline的Value設計，也是與Jetty的Handler類似的方式，要自己實現一個Value與寫一個Handler的難度不相上下。從表面上看，Tomcat的功能要比Jetty強大，因為Tomcat已經幫你做了很多工作，而Jetty只告訴你能怎麼做，如何都由你去實現。
打個比方，就像小孩子學數學，Tomcat告訴你1+1=2、1+2=3、2+2=4這個結果，然後你可以根據這個方式得出1+1+2=4，你要計算其他數必須根據他給你的公式才能計算，而Jetty是告訴你加、減、乘、除的算法規則，然後你就可以根據這個規則自己做運算了。所以你一旦掌握了Jetty，Jetty將變得異常強大。
性能比較
單純比較Tomcat與Jetty的性能意義不是很大，只能說在某種使用場景下他們表現得各有差異，因為他們面向的使用場景不盡相同。從架構上來看Tomcat在處理少數非常繁忙的連接上更有優勢，也就是說連接生命週期如果短，Tomcat的總體性能更高。
而Jetty剛好相反，Jetty可以同時處理大量連接而且可以長時間博愛吃這些連接。例如，一些Web聊天應用非常適合用Jetty做服務器。淘寶的Web旺旺就用Jetty作為Servlet引擎。
由於Jetty的架構非常簡單，作為服務器他可以按需加載組件，這樣，不需要的組件就可以去掉，無形中可以減少服務器本身的內存開銷，處理一次請求也可以減少產生的臨時對象，這樣性能也會提高。另外Jetty默認使用的是NIO技術，在處理I/O請求上更佔優勢，Tomcat默認使用的是BIO，在處理靜態資源時，Tomcat的性能較差。
特性比較
作為一個標準的Servlet引擎，他們都支持標準的Servlet規範，還有Java EE的規範也都支持，由於Tomcat使用得更加廣泛，他對這些支持得更加全面一些，有很多特性Tomcat都直接集成進來了。但是Jetty的應變更加快速，一方面是因為Jetty的開發社區更加活躍，另一方面也是因為Jetty的修改更加簡單，他只要把相應的組件替換就好了。而Tomcat在整體結構上要複雜得多，修改功能比較緩慢，所以Tomcat對最新的Servlet規範的支持總是要比人們預期的晚。
閱讀更多 程序員界的彭于晏 的文章
