三四年前更多地還是做web業務開發，基本不關心web層以下的東西，但是每次出故障時面對現象都不能從腦子裡形成由底層到應用層的完整的邏輯，往往只能分析到Web應用就無法繼續往下，Web容器完全就是一個黑盒，對於問題更多的是靠猜。舉個簡單的例子，應用突然就不服務了，此時如果對Web容器模型熟悉就可以直接jstack列印虛擬機器的棧進行分析。我個人接受不了這種用非完整性邏輯去分析事物的感覺，於是想著還是把Tomcat也一起搞定吧，處理故障時往往就能看到更本質的東西，而且還能對Tomcat進行定製。
為什麼選擇Tomcat？對於多數Java開發者，很多Web容器都是基於Tomcat的，同時Tomcat也最多人在使用，所以選定了Tomcat。
另外，做網際網路應用的人都必須要深入掌握一個Web伺服器，比如tomcat，比如nginx，比如apache。
在我看來Web伺服器將網路IO及執行緒併發處理還有協議等需要很經驗很豐富的高階程式設計師才能處理的好的事都遮蔽掉了，抽象出了另外一個高緯度的概念，大大降低了Web應用的開發難度，也提高了效率，但同時也讓上層開發的人很少有機會了解下層的東西，這對於處理故障和效能分析是十分不利的。所以說Web伺服器這個抽象有大利也有小弊。
怎麼深入？開始看《how tomcat works》，這本書很經典，它從0開始闡述了Tomcat如何工作，但這本書是基於Tomcat很老的版本，看完後我能瞭解大概的Tomcat機制，但我總覺得正在的工業級Web容器還應該有很多細節是需要處理的，而正是這些細節才成就了Tomcat成為一個工業級的Web容器，而這本書並沒有涉及到Tomcat裡面的細節處理及優秀的設計思想。
當我深入Tomcat原始碼後，發現從整體上理解一箇中介軟體的思想和區域性瞭解是完全不同的，整體上的把握更能體會設計者的思想及能更好地品味優秀的設計思想，以及你有些設計你也會覺得設計的不足。原始碼的精讀和泛讀是完全不同的概念，比如後來工作上用到了jmeter，我就看了jmeter的原始碼，用到lucene就看了lucene的原始碼，用了hazelcast就看hazelcast原始碼，同時也會看jdk怎麼實現就，用到cobar就看它的實現，用netty就會看netty實現，類似的還有zookeeper和hbase等。但沒有一個是能夠達到自己理想的精讀狀態，所以索性深入一個，那就是Tomcat。
另外，我發現市面上缺少分析Tomcat設計思想方向的書籍。
綜合上面幾點，想著那就自己寫一本吧。
對於快餐式的IT世界，花時間去深入研究原始碼設計值不值得？仁者見仁智者見智，從工作的角度上看，研究的東西都應該更好服務於自己工作，或者是服務於自己未來工作的方向，提升工作效率。而有時，慢就是快，現在花的時間都讓後面能走得更快。
《Tomcat核心設計剖析》前面也說過它的特點，它主要是側重於工業級Web容器的設計細節的剖析，而並非是原始碼分析，所以裡面基本很少有Tomcat的原始碼，正如書中前言說的“拒絕沒營養的直接貼程式碼分析，而是昇華到對Tomcat設計思想的剖析”。我個人覺得看懂原始碼可能很簡單，但要通過原始碼領會其中很多細節的設計思想卻不容易，所以這不是一本分析原始碼的沒營養的書。如果您預期是想看原始碼分析，那麼這本書不適合您，請您不要購買。
最近看到有兩位讀者朋友給的中評，評論如下，其中我看到都有提到程式碼太泛，關於這點，“如果您預期是想看原始碼分析，那麼這本書不適合您，請您不要購買。”。另外感謝第一位讀者給的肯定及建議。本書很多與部落格一模一樣是因為部落格其實就是編寫本書時的一些章節，考慮到先發部落格有錯誤或理解不到位的地方讀者會提出來，這也能更好地保證照籍的質量，所以並不是敷衍。
