五年java人的一点感悟

恍然间,发现自己在这个行业里已经摸爬滚打了五年了,原以为自己就凭已有的项目经验和工作经历怎么着也应该算得上是一个业内比较资历的人士了,但是今年在换工作的过程中却遭到了重大的挫折。详细过程我就不再叙述,在此,只想给大家说一说被拒绝的原因,看看大家有没有相似的经历,和类似的感悟。面试官对我的答复大致是这样的,我们不需要熟练工,我们需要在某领域拥有超过常人的积累认知,和拥有整套完整思维模式和优秀认知事物能力的人…他很诚恳地告诉我,你还年轻,真的应该好好地静下心来,深入地研究一些东西,自己写一些东西,而不是这也用过,那也知道,但是多半都是局限于仅仅见过,会用,却从来没有认真思考过其代码背后蕴含的思想,更少有人研究过源码,进而体会大师们在某些问题的解决上秉承的思想和思维的风格。个人感觉,这也算是国内大部分程序员最让人悲哀的地方了,当然这也与外界浮躁氛围的蔓延不无关系。不了解这一行的人总觉得程序员都是代码民工,如果自己也认为自己是敲代码的机器的话,我诚恳地建议您尽早转行吧,也许我这么说会得罪伤害一些同行,毕竟转行对任何一个人来说都是有相当的风险和挑战的。不过这绝对应该是善意的忠告。相反,我强烈地认为,程序员应该是最有活力和最有思想的一个群体,只要你不肯让自己浮于表面,更重要的是,必须勤于思考。如果你认可我这句的话,就请您继续往下看看我的感慨,否则,那就希望您好好利用好自己的时间做您最需要做的事吧。
由于面试中被问到tomcat的时候,让面试官问得人仰马翻,哑口无言,所以回来之后洗心革面,下决心要把tomcat好好研究个明白,再也无法容忍自己只知其一不知其二了。于是上阿帕奇的官网上找文档找资料,当源码,在一些技术论坛找高人的分析帖子,并且搜罗相关的书籍,无奈一番折腾后都不能让我满意,因为一千个人对一个事物或许会有一千个看法和观点。网上此类介绍tomcat的技术类帖子更多的都是些抄袭,说到这里,本人在此郑重声明,做技术的人应该恪守一点职业道德,那就是责任心(我曾经给自己取的网名就是扯嗓门讲大道理的人),你想给大家讲某个东西的话,必须应该是自己真正亲自分析研究过的,这是最最起码的要求,千万不能东抄一点西抄一点拼凑,不懂瞎装,瞎写,这是极其让人鄙视的态度,虽然当下这个时代,大家确实都比较浮躁,而且急功近利,但越是这样,就更需要大家坚守自己,尤其是做技术的人,对技术必须秉承实事求是,严谨,务实的态度,彻底刨掉那些虚华的东西,这样我们才敢从心态上说我们称得上是一位真正做技术的人。
好了,说了这么多废话,浪费大家时间了,下面说说我对tomcat源码研究的几点展望,众所周知,tomcat是一个开源的Servlet容器,而这个容器的主要作用就是负责处理和响应客户请求(我们暂且忽略其他的一些次要的方面)。那么好,我们可以先做这样一个比喻,tomcat应该可以比作一部机器,这部机器可以接受客户端的请求,并返回一个结果给客户端,而且这部机器的原材料是java。那么我们想知道,这部机器的结构是怎么样的?它的组成部分有哪些,这些组成部分是如何被组织到一块的?这应该是第一步,即对tomcat的整体组成要有个纵览,知道tomcat这部机器都有些什么组成部分,知道每一部分主要都负责了什么工作,这一点非常重要;那么第二步,就是,这部机器是如何启动的?《精通tomcat》一书中把tomcat比作一部发动机,再恰当不过了,因为在它正常提供处理客户端请求的服务之前,它得先完成它的启动,我拿到源码之后(版本号是TOMCAT_6_0_12),也是参考《精通tomcat》一书的指导,找到Bootstrap类,然后Dubug as Java Application,一步一步跟源码来研究tomcat的启动脉络。大家知道,tomcat是一个基于组件的服务器,那么完成了第一步工作,我想大家应该大体都会知道tomcat里面都包含了哪些组件了,那么通过第二步,我相信大家对这些组件是如何组装并启动的这个问题,就会有一个比较初始的认识和了解了。我们在日常工作中的系统设计和开发处处强调松耦合的思想,那么我想tomcat里面这些组件的组织将会是一个非常典范的案例值得我们研究和学习,人家是如何组织自身的组件的,如何装配的,这个问题,需要大家对digester技术有所研究,当然现在digester已经作为阿帕奇的一个common项目了,大家可以当相关的文档和源码进行深入研究这个技术,我也正在研究学习中,希望大家共同学习共同进步。那么再完成了前两部,知道tomcat里面都有些什么,并且知道tomcat的启动流程之后,我觉得就应该对tomcat应答一次请求的全过程进行细致深入的分析了,客户端发出向tomcat发出请求之后,tomcat是如何处理的?最先是那个类那个方法来响应,那个组件最先接到了请求的,之后它具体都做了什么,整个过程的处理逻辑和原则是什么样的?搞懂了这些,相信对tomcat的任何返回结果就再也不会感到意外和困惑。遗憾的是,我目前只看到很多地方粗粗地这么介绍:请求被发送到本机端口8080,被监听的HttpConnector获得,然后再由Connector交给Engine处理,再匹配名为localhost的Host处理,紧接着由Host匹配Context,再找JSPServelt类等等,这些介绍我目前还深表怀疑,貌似正确,其实说得不免有些笼统,当然也不能说完全错误,因为我目前还没彻底搞清楚这个问题,也不敢贸然下结论,我只是跟了源码后发现,请求来了先运行的是CoyoteAdapter这个类的service方法,实践出真知,还是希望大家亲自跟跟源码去理清楚其中玄机,看看tomcat接受请求处理请求的过程到底是怎么样的?我觉得只有搞清楚了这个问题,才敢说自己对tomcat算是真的懂了一些,至少tomcat对自己不再是个黑盒了。这个过程我目前还在进行中,由于自身能力有限,尚需多少时间能彻底搞清楚还是个未知数,但是我愿意继续努力,今天由于时间原因,先写到这里,我会继续发帖向大家汇报我的进展,更加希望能得到众多高人的指点,不甚感激,谢谢大家。

也许大家觉得我有点罗嗦了,不过确实也是很啰嗦,呵呵,我以后会努力改进,估计很少有人能耐心看完整篇帖子,更没心思猜我发帖的用意了。那么我就做个小结吧。本人面试受挫后,突然醒悟,觉得自己是得真真正正地做点事儿了,做点有价值的事儿了,那么我果断给自己定了个这样的目标,就是彻底研究透tomcat,并且重写出一个MyTomcat,绝对不会是山寨,这个名字也是自己突发奇想而已,当然也是开源的,咱们中国做Java的人,不为开源界做点自己的贡献的话,实在有点惭愧。希望嘲笑讽刺的同学们绕行吧,欢迎广大有识之士加入这个目标的奋斗中。发帖算是抛砖引玉吧,谢谢大家。

某个领域应该是业务领域吧?都是做应用的,花大精力研究源码是不是南辕北辙。

2011年09月29日 10:31 "@jeffrey4chartcrm"的内容
某个领域应该是业务领域吧?都是做应用的,花大精力研究源码是不是南辕北辙 ...

首先,谢谢jeffrey4chartcrm 同学的关注和回复。其实我上文中提到的这个领域肯定不仅仅指的是业务领域,肯定还应该是包括技术领域的。咱们做技术的人估计最初多半还是从技术开始的,但是对于咱们这一行来讲,满足业务需求又是我们永恒的方向,也就是说业务是灵魂,技术仅仅是为业务服务而已。这个观点想必多半人还是认同的,那么为了更好地完成我们技术人的使命,我们的武器一定要精良,当然指的就是我们对技术的认识和掌握了,只有精通了技术,才有可能很好地完成我们的使命。我就是不想再做个熟练工了,所以想花大力气研究学习源码以提高自己的内功,进而提升自己的专业素质和能力。所以,我觉得花点时间研究源码,应该算不上南辕北辙吧,更多地应该算是磨刀不误砍柴工吧。何况对于闻名遐迩的tomcat来说,做Java的人如果永远对它都敬而远之,而仅仅是用过,会用的水平的话,是不是有些惭愧呢,大师的作品就摆在面前,我们真的没有理由不好好地虚心研究和学习,难道我们不该向大师看齐吗?还是那句老话,一定鄙见,欢迎高人“拍砖”。

2011年09月29日 11:45 "@KenWT"的内容
面试官对我的答复大致是这样的,我们不需要熟练工,我们需要在某领域拥有超过常人的积累认知,和拥有整套完整思维模式和优秀认知事物能力的人 ...

我觉的这位面试官是你的贵人,他说的很对,5年的经验如果仅仅是使用开源框架,那真的是一种悲哀,资深的技术人员是必须钻研一个领域的,这个领域有几个层面的东西,一个业务领域、一个是技术领域。业务领域很明显需要清楚的需求,技术领域就是计算机科学,大家都是做技术的,哪个领域适合自己,只有自己最清楚。
另外我想说明一点,一开始就去看源码,我保证能读懂70%就不错了,有很多基础性的东西你真的掌握里吗?举个简单的例子:如果源码里有一个优先队列,当你看源码的时候你能看出来这是一个优先级队列吗?或者一个多路归并排序,你能看出来算法思路吗?
我再次强调一点,如果没有数据结构和算法的基础,是无法和优秀的程序员对话的。

2011年09月29日 12:32 "@zzxsky1986"的内容
我觉的这位面试官是你的贵人,他说的很对,5年的经验如果仅仅是使用开源框架,那真的是一种悲哀,资深的技术人员是必须钻研一个领域的,这个领域有几个层面的东西,一个业务领域、一个是技术领域。业务领域很明显需要清楚的需求,技术领域就是计算机科学,大 ...

首先,还是老规矩,谢谢zzxsky1986同学的“拍砖”。那位面试官确实算是我的贵人,让我突然清醒了过来,自己是该调整调整前进的心态和思路了。这一点,我们的观点是一致的。所谓闻道有先后,干了5年的我,目前还只是在熟练工的圈子里转悠,确实是件让人深感悲哀和惭愧的事儿。我一定会多多努力,希望大家也能多鼓励我。我的目标,我已经说过了,大家嘲笑也罢,讽刺也罢,都不会动摇我前进的步伐。同时,我会加紧整理总结我的研究进度,并及时发帖,欢迎大家监督并一同探讨,共同进步,旨在将来,我们这些人也能为开源界做出一点点属于我们自己的贡献,那将是一件多么让人深感光荣和自豪的事。
至于您说的第二个观点:如果没有数据结构和算法基础,就无法和优秀的程序员对话。这个观点,我还是想暂时保留一点自己的意见。从您的字面意思,不难看出,如果不谙练数据结构和算法的话,就无法真正读懂领会源码??这个观点依我目前的认识真的暂不敢赞同,记得帮主也曾经在一篇帖子里说过,国人学东西往往会陷入一个误区,比如咱们搞软件的人,如果连数据结构和算法都不过关或者说深入研究过的话,是不可能写出真正有价值的代码和程序的,而一般人一旦一开始就埋头于这些基础理论的话,多半都会深感枯燥乏味。就相当于是一个没打过仗的士兵去学习各种精良武器的使用一样,或许他是个超人,悟性相当高,没打过仗,但是谙熟各种武器的使用之后,上了战场也能把各种武器的优势发挥得淋淋尽致,这种情况绝对应该是存在的,我不否认。不过,我觉得自己不是这样的人,我应该属于打过一些小的战役,有点实战的经验,比如说什么时候该用长枪,什么时候该用短枪,还是见过别人用过的,下次在打一场大战役的时候,我手里常用的长枪坏了,我临时捡了一杆新的长枪,看别人怎么用,我也就跟着用了,还发现很好使。。。不好意思,我又啰嗦了,我的意思,我想我已经表达清楚了。至于怎么学习,一百个人绝对是可以有一百种方法的。绝对不应该很贸然地下这样或者那样的结论,我深深地感觉到,程序员这个群体,大家的思维应该是最活跃的,也应该是更加包容和开放的,今天的观点理论很可能在今天下午或者晚上就被一种全新的思维彻底否定掉。这是其一,就是一个态度的问题,活跃,包容和开放。其次,就是研究学习的方法,这个话题说起来就更没个头了,我只是想介绍一下我目前的方法,而且我固执地认为这个方法确实对我很有成效。首先,坦白地说,数据结构和算法,我也就略知皮毛,大学时看那点东西很快就还给老师和书本了,这方面我深知自己底气不足,而且我知道能力和水平想有质的提高的话,这块绝对是应该高度重视的。再者,我现在研究Tomcat的源码,我的指导思想,就是先搞懂它的产生背景,组成以及功能;然后再跟源码搞清楚它的启动过程是怎么样的,从哪儿开始,经历了那些过程,做了那些事,最后启动完毕了,可以提供服务了?最后,就是对它提供一次请求应答的全过程,进行深入细致地研究,那个组件接受请求,怎么接受的,为什么会这样接受?那些组件处理请求,怎么处理的,为什么要这么处理?处理的流程和逻辑是什么?其间,我都是先暂不考虑其他的一些东西,尽量先把握这个主线来研究,主线理通了,再一层一层理外围的一下东西,以此来揭开Tomcat神秘的面纱。最后,我肤浅地认为,什么算法,什么结构,都是为了某种思想服务的,或者说是某种思想的一种实现体现罢了,而某种思想又都是为了解决某个问题而诞生的。这么看来,其实真正重要的并非这算法那结构,而是对问题的认识和抽象,以及解决问题的思路,只要时刻把握住了这两点,我认为应该就能保证自己的前进的路不会走偏,您觉得呢?先唠叨这么多吧,老规矩,鄙人鄙见,欢迎“拍砖”。

呵呵,等你再多研究一下tomcat的源码,就自己就会去研究数据结构和算法了,这个是需要经历一个过程的。
其实说句老实话,计算机就是在用数学解决现实问题。任何一个人想要回避都是自己在欺骗自己。

另外我补充一点,解决问题的方法(也就是大家认为的流程),这个概念其实并不复杂,这个工作也不复杂,而且很多程序员也就是停留在设计这些流程上,高级一点的就是会想到用什么结构或者技术(已有的)能使流程变了但是代码能少变点(这就是一般大家眼里的架构师),大家可以想想再复杂的工作流总要是有一个步骤的,如果你只是明白里这个流程,有什么用啊?如果不了解细节,告诉你,一点用都没有,就好都知道操作系统运行程序的流程,什么先编译成机器吗然后装入内存然后由CPU调度计算什么的,你知道这些有什么用啊?能写个操作系统出来吗?
设计软件程序的难点在,知道流程以后如何能写好程序,那么OK,怎么写程序?怎么写出高效的程序,再举个例子,虽然我没有看过tomcat的源码,但是我认为tomcat肯定有线程池的吧,难道是直接使用的jdk的线程池吗?为了细粒度的控制性能,应该是会自己实现,那么要想实现线程池,用什么数据结构?线程池用什么算法?如果你不是想弄明白这些,那我不清楚你看tomcat的源码是想弄清楚什么?

还有就是大家一直在说设计模式,大家在项目中能用到几个模式?哪一次需求变更不是多少都需要重新开发,单靠加间接层这种代码要是能维护就怪了。
[该贴被zzxsky1986于2011-09-29 15:41修改过]

2011年09月29日 15:18 "@zzxsky1986"的内容
呵呵,等你再多研究一下tomcat的源码,就自己就会去研究数据结构和算法了,这个是需要经历一个过程的。
其实说句老实话,计算机就是在用数学解决现实问题。任何一个人想要回避都是自己在欺骗自己。

另外我补充一点,解决问题的方法(也就是大 ...


谢谢zzxsky同学的再次“拍砖”!我们暂且先不再继续讨论你我对数据结构和算法对于个人修炼提高的重要性,这个问题你我的认识程度暂且参差有别确实是客观存在的,这也很正常,我自己在这方面也会加倍努力学习。


再者,就是您表达的第二个意思好像是“流程无用论”吧(我姑且先这么称谓,不合适的话,您再拍砖),我觉得您应该是对我有所误解,我现在每天都抽时间跟Tomcat的源码,目的就是为了细化对流程的认识,应该算是了解和学习主要流程的纯粹的细节了,这个环节是我研究的初步阶段,也是一个不容忽略的阶段,而且至于我本人研究Tomcat的目的,我之前也有向大家交代过,我试图在未来重写Tomcat(也许大家会觉得可笑和荒谬),所以第一阶段,对流程以及细节都必须要有足够深刻地认识和把握,这个论点,您应该不会有异议吧。以我目前自身的能力和潜质,我还绝对不敢号称自己有写出一个新的操作系统的想法和目标,那对自己来说,真的有点渺茫和不现实。但是重写Tomcat对我来说却绝对没有像写一个新的操作系统那么难以实现。尤其是对做Java的人来说,同样是做Java的人,为什么人家能用Java写出了如此伟大的web容器?这真的值得我们深思的一个问题(拒绝所有抱怨和妄自菲薄),即使最终我无法完成自己重写Tomcat的目标,我想我研究问题的能力以及各方面综合素质和能力也会得到巨大的提高。到那时,我相信只要是Tomcat相关的一些实际问题,相信我至少会比没有深入研究过的人能更快定位问题并解决问题。好了,尽量不浪费篇幅罗嗦这些次重要问题。


最后,我诚恳地提个小小的建议,本人拒绝一切泛泛而谈的逻辑和理论,因为我并没有太多特殊的经历和感悟,在技术这座山峰面前,我还在跋涉的途中而已,而且面对我的目标,我目前稍显势单力薄,所以我希望能有有识之士加入这个目标,共同研究,不知您意下如何?另外,说到Tomcat的线程池问题,我想先说一下我目前这个版本所包含的线程池的一些情况,我目前拿到的源码的版本是6_0_12,这套源码中,我大致看了一下,应该是包括了两类五种线程池的方案,第一种就是APR的Pool技术,使用了JNI,源码名称AprEndpoint,那么第二类就是Apache使用Java实现的线程池,分别有BasedEndpoint,JIoEndpoint,NioEndpoint,PoolTcpEndpoint。目前对该版本的线程池的了解情况也仅此而已,因为我的研究进度还没到这里,更多的细节目前还说不出来什么,其实我很希望你能加入到这个目标中来,就用闲暇时间,你独自对Tomcat的线程池进行研究,然后等我研究完了,咱俩再交换一下彼此的研究成果,这样的话,我估计咱们的交流会更有 成效,您说呢?再次感谢关注和“拍砖”,诚待您的回复。谢谢大家

抱怨设计模式的人,是因为没有经历过设计模式带来的好处。设计模式易扩展易维护不轮到某些人一句否决,事实和经验得到验证。换个线程池轻松,曾个监听器轻松,责任分离通过链传递等等,这些都使我们更好去适应变化。需求变更就变化很大,这只能说明某个问题而已。

从更根本上的逻辑发生变化,再强大的设计模式也不是“银弹”,设计模式是面对着什么样的变化才有效,不了解清楚就使用,很容易发生误用。一个模式解决一个或者一类问题,每个模式都有其目的,不能滥用。本来不需要用的却硬要去用,就别怪模式了。错的不是模式,而是使用模式的人而已。

JDK和tomcat都有大量的模式,读不出不等于没有。而且除了JAVA外,设计模式在各种语言都有各种方式去实现,甚至有些已经直接提升到语言级别,所以设计模式只是很纯粹思维的东西而已。

何为“好”代码,每个人,每个角度都有不同的说法。与其说这些含糊的词语,不如说“伸缩性”“扩展性”“高效性”……拥有明确的目的,明确的思维,才能学好东西,用好东西。

“牵一发而动全身”?想不想随你~

2011年09月30日 15:30 "@SpeedVan"的内容
抱怨设计模式的人,是因为没有经历过设计模式带来的好处。设计模式易扩展易维护不轮到某些人一句否决,事实和经验得到验证。换个线程池轻松,曾个监听器轻松,责任分离通过链传递等等,这些都使我们更好去适应变化。需求变更就变化很大,这只能说明某个问题而 ...


谢谢SpeedVan同学的关注和“拍砖”。看了您的回复,我想您首先应该是表达了这么一个意思吧,在自己没有真正彻底领悟设计模式之前就滥用设计模式是不理智的,对吧?这个观点,我非常赞同,所以就更加突出显示了学习的重要性。然而我们之中不乏这么一些人,或许是自诩悟性非凡,不懂偏要装懂,或者就是为了模式而模式;另一方面,更多得我觉得确实也应该是由于时间所迫,相信这个大家都有类似的体会,情况就是我们确实也想多一些思考探讨和设计,尽量把事情做得尽善尽美一点,但是实在是项目上线时间紧,反正大环境所迫吧,等等一些原因。其实大家都明白一种思想和理念的领悟真的绝不应该是一朝一夕就可以做到的,只能提醒自己尽量不要再犯滥用模式或者任何某种尚未搞懂的技术,这显然是不理智不科学的。这一点真的应该是我们这些人研究和学习技术的非常非常明确的大前提。


其次,还表达了您对设计模式本质的体会:设计模式只是很纯粹思维的东西而已。这个观点我暂时还无法完全理解,而且我对设计模式的认识和理解也还并不深刻,不过,既然谈到这儿了,我也不妨说一说自己的一点鄙见,我觉得设计模式它的根子应该是它诞生的动机,也就是为啥会有这模式那模式的,其实在我看来,都是为了应对软件系统未来可能会发生的这样或者那样的变化而产生某种应对策略罢了,就是为了防止彻底的重构,推到重来。隐约间,也就这么点认识,欢迎大家拍砖,时间紧迫,原想详细说说自己相关的一点经历呢。节后吧,我尽量尽早给大家补上。


那么第三个意思呢,我想我和您的观点是一致的,再次声明,拒绝泛泛而谈。其一,这样很容易让我们迷失方向和失去专注,另外就是您谈到的,拥有明确的目的。我非常之认同!我们评价任何代码也好,方案也罢,都应该是有前提的,那就是在具体的场景中对它进行客观,严谨的评价,绝不能忽略了这个前提。山寨一句老话,从实际中来,再回到实际中去。任何理论和逻辑离开了实际问题的支撑,都只能是空洞而毫无意义的。欢迎大家继续关注和“拍砖”。以此共勉大家不断虚心学习和共同进步。谢谢大家,祝大家节日快乐。

我试着给出一些看法与建议,有用,你就当做参考,无用,就拉倒。

一、just undo it!
1、金钱因素,如果这项技术不值钱,不能够解决自己的基本生活需求,不值得学;(吃饱了,喝足了,才能撑着干活)
2、时间因素,如果投入的时间成本太大(你没有充足的闲暇),不值得学;(生命如此短暂,掌握技艺却要如此长久。)
3、心智因素,不能促使心智健康成长的技术或知识,不值得学;(开卷未必有益)

二、just do it!
1)反思已有的经验,和探求未知同样重要。
2)技术是拿来用的,不是拿来学的,学也是为了用。
3)没有白箱,没有黑箱,只有灰箱,认知是无止境的过程。

5年了,你也许先要做的是对5年的经验进行提炼,形成自己的思想和解决问题的方法。

比如,怎么阅读源码?怎么组织代码?怎么给函数、变量、类、包、文件取名字? 怎么划分模块?怎么掌握一门新的技术?碰到疑难杂症时怎么办?区分那些知识是了解即可,那些知识是需要深入理解与记忆的?等等。

甚至,你可以问一些更基本的问题,让自己尝试作出回答,比如软件是什么?程序是什么?算法是什么?数据结构是什么?模式是什么?架构是什么?不必苛求自己给出完美的答案,这样去做只是为了让你看得更透彻些。

Tomcat是Servlet/JSP(= in-out servlet)的容器, 那么Servlet是什么?Servlet实质上是用Java语言对HTTP协议的封装,而Tomcat是HTTP服务器的一种实现。

HTTP服务器有很多种,除了Apache的Tomcat,还有Nginx, IIS, LiteSpeed, ……等等,显而易见,你一辈子也学不完。

对于Tomcat源码(我没有研究过,因为还有别的事情要做,目前也没有这个需求),我建议你参照HTTP协议(RFC2616)进行研究,深入了解HTTP协议的交互过程(除了服务器,还包括去理解浏览器的行为,因为这才是完整的交互过程),应该可以起到事倍功半的作用。

阅读协议RFC文档是一件非常枯燥的事情(相对于可运行的源码枯燥得多),你最好有心理准备,我建议的阅读方式是:以英文为主,中文为辅(RFC文档不好翻译,这不能怪译者);分段分层次阅读(比如,先大致了解全貌,而后分成若干层次,在不同的时间段进行细致、反复的了解)。

协议和算法一样,我们是学不完的,深入理解常用、极少量的一小部分(比如HTTP、URI协议规范, 比如排序、检索算法等),才是切合实际的。

一种技术,如果它非常实用,你也非常感兴趣,不妨就长久地投身于此,在一片小小的天地里,做出自己的成绩。

我觉得楼主应该缺少一定业务分析理解能力,有点浮躁,对有工作5年的技术人员,除了技术问题之外,应该对自己从事的业务领域有自己独特的理解(每个人都不一样,个人认为这是非常重要能力),如何通过技术来解决某领域的业务问题,必须有自己的一套解决手段,这通过面试沟通是可以看出来的!我觉得面试官肯定是看出你这方面的欠缺。
对于Tomcat的问题,我觉得在国内的公司,大部分应该不需要你熟读Tomcat源代码、非常了解Tomcat的技术细节,因为很多公司不可能设立一个Tomcat技术专家的职位。 一般面试提到Tomcat更多的是通过Tomcat来了解你对 J2EE 技术架构的理解,比如:Web应用服务器运作原理、线程池、Servlet生命周期、性能问题、分布式处理等等这些东西,这些知识如果你在实际工作中有用到,并且有花精力去理解,那肯定会形成自己对技术原理理解。

说的很对,只可惜我还没到那个境界啊!!!

是啊 讲的很对。。。希望能看到你写的mytomcat.

顶你,讲的很对,读了源码不一定能说明什么。我觉得要考量好,我很同意banq所说的向下思维的危险性。应用驱动学习,先用好了,再研究原理,不能熟透了源码才敢用tomcat