为什么写《Tomcat内核设计剖析》

三四年前更多地还是做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设计思想的剖析”。我个人觉得看懂源码可能很简单，但要通过源码领会其中很多细节的设计思想却不容易，所以这不是一本分析源码的没营养的书。如果您预期是想看源码分析，那么这本书不适合您，请您不要购买。

最近看到有两位读者朋友给的中评，评论如下，其中我看到都有提到代码太泛，关于这点，“如果您预期是想看源码分析，那么这本书不适合您，请您不要购买。”。另外感谢第一位读者给的肯定及建议。本书很多与博客一模一样是因为博客其实就是编写本书时的一些章节，考虑到先发博客有错误或理解不到位的地方读者会提出来，这也能更好地保证书籍的质量，所以并不是敷衍。