Bitter Java中文版

　　本书系统地介绍了常见的服务器Java编程错误，以及这些错误产生的原因和解决方案。书中涵盖了基本Java和J2EE概念的反模式，如servlet、JSP、EJB、企业连接模型和可扩展性等，通过代码示例展示了Java编程中常见的陷阱，还提供了重构代码，并解释了为什么新方案是安全的。本书适合中级水平的Java程序员、分析员或架构师阅读，通过研究书中介绍的反模式，可以吸收别人的经验教训，在工作中少走弯路。[前言]到了夏天，得克萨斯河水就几近干涸。为了寻找急流，漂流者不得不跟着暴风雨的脚步走。那是1996年夏天的一天，我和一个同伴晚上8点离开奥斯汀，冲入狂暴的风雨中，一直来到阿肯色州的Cossatot河。等我们到了那里，坏天气好像跟我们开了个残酷的玩笑，居然绕过这条河径直走了。我们筋疲力尽，失望之极，只好在河岸上扎营休息。那天晚上我们根本没有听到一丝雨声。到了早上，我还是垂头丧气，头昏眼花地走出帐篷，然后几乎跌倒……在河里。Cossatot河素来就有涨水极快的坏名声，仅仅因为上游10英里处下了2个小时的雨，水位就突涨了6英尺。现在我们倒是可以漂流了，但是水位又太高。我们决定等第二天早上再来对付难度大的这一段，先到相对容易一些的上游漂流。原来水流迟缓的1级水域现在已经变成了汹涌的3级急流。指南上说这一段要漂流“4个小时”，但我们只花了20分钟就飞驰而下。“中间”河段更糟糕：湍急的河水已经达到4级，猛烈地咆哮着。经过仔细侦察，我们轮流在河岸上执守，一个人在河水中漂流时，要系着安全带，由另一个人在岸上监视情况。然后我们把皮划艇放在营地，徒步走下去，看看下面的河段情况怎么样。让我们惊讶的是，居然有几十个当地人在河岸旁放着躺椅，像看风景一样看着河面。以往他们看到的只是4级瀑布，如今这条河已经完全被可怕的大漩涡所笼罩。此前，我们很少看到当地人，他们在这里只是看有没有人出风头，有没有惊险的事情发生。这种景象让我们目瞪口呆，所以我和同伴也各自坐在一块大石头上开始看热闹。追溯到2000年，尽管当时我的职位已经不低，而且待遇优厚，但我还是离开了IBM，去加入一家名叫allmystuff的创业型（startup）公司。当时经济已经开始衰退，但是在奥斯汀其他创业型公司纷纷垮台之际，这家公司却刚刚拿到了赞助。这家公司的企业运作并不取决于广告收入，所以尽管广告收入日薄，似乎也影响不大，另外allmystuff里集结了许多精兵良将。我加入公司之时，它的银行资金有一千万美元，不仅有固定客户，而且拥有着高新技术，这一切都预示着它很可能成为炙手可热的成功企业。我见过许多朋友都离开IBM大旗，转而投奔其他公司，虽然新公司的待遇不能比，也没有安全感，但是很有冒险性。我想反正在必要时还可以回去，所以面对着即将到来的黑暗，我迎头冲入到这场风暴中。在奥斯汀新闻笑谈曾经红极一时的创业型公司都纷纷落马之时，allmystuff也开始在困境中挣扎。我们日以继夜地工作，为很少的几个客户部署解决方案。尽管我们的质量一流，有让人自豪的业绩记录，但最后还是被衰退的经济所累。风险投资者决定最好还是关门大吉，再找寻一种适应这种经济衰退局势的新概念东山再起。尽管这件事本身让人很难受，但是在我的职业生涯中，那个时期我学到的东西却是任何其他时候都比不上的。就像Cossatot河岸上的当地人一样，如果一个冒险故事是我们身边发生的真事，很刺激，甚至很危险，那我们大多数人都无法抵挡它的吸引力。不论是看一个久负盛名的希腊悲剧故事，还是看像电视剧“生存者”（Survivor）这样一些最新的流行节目，我们的猎奇思想永无止境。程序员也不例外。我们很喜欢聊最近发生的冒险事情（我们把这称为“实境谈话”（merctalk）），这有很多原因。我有许多鲜活的工作记忆就是在allmystuff的乒乓球台边留下的。在那里我们讨论过管理哲学；讨论过代码基是不是已经失控；另外还讨论过，与日益复杂的JSP模型相比，有专门浏览器的XML是不是一种更简单的方案。我们还讨论过，眼看着进度不断推迟，图形化设计人员能不能把他设计的用户界面映射为越来越复杂的Java命令。正是这些讨论燃起了我的热情，促使我离开了原本安稳的职位，做着百万富翁的梦，投向这个待遇更低、没有安全感的新工作。这些经验使我成为一个更好的程序员、管理人员和架构师。不记得在哪个场合下，前IBM主席JohnAkers曾说过，太多的人“整天都只是喝水聊天，无所事事”。我记得听了这话我们都很生气，他不知道，往往在喝水（或喝酒）时或者在乒乓球台边听到的东西会决定一个项目（甚至一个公司）的成败。在这里，必须听些程序员的故事，受些熏陶，因为这些会影响一生。我准备把其中一些故事放到《BitterJava》这本书里。再回到早先，那时我还没有加入allmystuff，正准备在一个会议上演讲。我报告的题目是“BitterJava”。在会议期间，我遇到了一位著名的Java程序员，JSP的创始人之一。他告诉我曾经在Pamplona参加过“公牛奔跑”（runwiththebulls）活动（译者注：这是一个很经典的活动，人们拼命地在公牛前面奔跑，一路上公牛会踩伤、踢伤或用角刺伤很多人，但人们还是乐此不疲，认为这是勇敢者的游戏），还被刺伤了。他还很起劲地给我解释他在参加公牛奔跑时的策略。我对他讲的不以为然。在Pamplona，早有无数的人告诉过我怎样避免被刺伤。我还向O.J.Simpson咨询过这方面的问题。每年都有数万个热衷于此的人参加，但只有十几个被刺伤。不过，慢慢地我有了想法：如果我要参加公牛奔跑，那我就会和他讨论。我想知道他是怎么计划的，他又怎么实施他的计划，哪里出了问题。这些信息我能用得上。后来发现，这个被刺伤的程序员正是allmystuff工程部的副总裁，他招募我帮助建立他的服务机构。再来说我的报告，尽管讲这个Pamplona故事可能会让我失去在allmystuff工作的机会，但我还是决定用这个故事来开始我的演讲。它充分体现了《BitterJava》中的概念。要说能帮助避免一个微妙的圈套或陷阱，一个关于失败的故事往往抵得上10个成功的故事。这个故事牢牢地吸引住了听众，而且……我也得到了我的工作。像许多程序员一样，我很喜欢极限运动。我们曾划着小艇遭遇危险，有时甚至遇到生命危险。WilliamNeely曾经讲过漂流界很有名的一个法则：你注视一个急流的时间与它吞掉你的危险往往成正比。换句话说，如果看上去漩涡大到能吃掉你，它很可能就会吃掉你。漂流者有自己的一套办法来描述如何沿河下行。漂流指南中会指出一条路线，还会指出路线沿线以及路线之外的一些危险地方。指南中可能说，“接下来，你会看到中间有一块大石头，你要向左。如果误撞到右边，那这个急流就会成为‘终结者’，用残酷的方式告诉你错了。”我很清楚，即使你没有真正了解一条河的威力，你也很想知道哪些地方可能出问题。我想知道水下有没有岩石，有没有陷阱等着我。我想知道哪里可能遇到漩涡，怎么躲过瀑布底下的大石头。我想知道，是不是有人在这条河上丧生，那是怎么回事。如果没有足够的了解，就算有高超的技术，我往往也会回避，甚至顶着小船沿河岸一路走下去，就是不下水。程序员（包括我）也是一样。我要了解应用和项目会在哪里失败。我要知道是不是与某个接口的通信太多了，所用的技术能不能解决这个问题。我得明白一个技术可能在哪里出问题，这个技术能不能扩展。我深信，要想成功，软件开发中总少不了失败，而且势必要从中学习。我还没有看到哪个组织能系统地从错误中学习，并以正规、系统的方式仔细分析为什么要修改一个有问题的设计模式或过程。我曾经看过许多代码，但并不是所有代码都很好。我已经领会到“bitterJava”的魅力，希望你也一样。

　　BrunceA.Tate在IBM和一家创业型公司有14年的工作经验，其中一半时间都在担任Internet架构师。他还著有另外两本计算机书。

第一部分　基 础 知 识
第1章　Bitter传说        2
1.1　自由降落的Java开发        2
1.1.1　生活中的反模式        4
1.2　使用设计模式强调正面        4
1.2.1　设计模式在线资源        5
1.2.2　UML为模式提供了语言        6
1.3　反模式从负面学习        6
1.3.1　一些著名的反模式        6
1.3.2　实际中的反模式        7
1.3.3　反模式资源        8
1.4　反模式的思想并不是全新的        9
1.4.1　从业界学到的教训        9
1.4.2　检测工作        10
1.4.3　重构反模式        11
1.5　为什么写这本书        11
1.5.1　本书方法        12
1.5.2　本书工具        12
1.5.3　本书组织结构        12
1.5.4　本书读者对象        14
1.6　前瞻        14
第2章　状况之苦        15
2.1　反模式滋生的土壤        15
2.1.1　分层的好处        15
2.1.2　分层也会对我们不利        17
2.2　Internet技术        18
2.2.1　Internet拓扑结构会影响我们的应用        18
2.2.2　企业层可以增加安全，也会加大开销        19
2.2.3　标准提供了Internet支持，同时增加了层        21
2.2.4　TCP和IP提供底层通信        21
2.2.5　HTTP提供应用级传输        22
2.2.6　HTML和XML        22
2.2.7　小反模式：Web页面上有太多元素        23
2.3　对象技术和反模式        25
2.3.1　封装有助于隔离修改        25
2.3.2　继承支持共同行为的打包        26
2.3.3　多态支持灵活的重用        26
2.3.4　小反模式：过度分层        27
2.3.5　Java的舞台        28
2.4　Java技术解决反模式        28
2.5　瀑布的主要问题        30
2.5.1　迭代方法        31
2.5.2　小反模式：不完整的过程转换        31
2.5.3　编程新视野：极限编程        32
2.6　状况之苦速览        33
2.7　本章介绍的反模式        33
第二部分　服务器端Java反模式
第3章　servlet之苦        37
3.1　孤注一掷        37
3.1.1　早期的反模式：神奇按钮        37
3.1.2　利用模型-视图-控制器模式构建        38
3.1.3　未能分离模型和视图        39
3.1.4　分出模型        40
3.2　反模式：神奇servlet        41
3.2.1　可以使用servlet作为模型吗        41
3.2.2　落入神奇servlet陷阱        43
3.2.3　导致神奇servlet的原因        46
3.3　解决方案：使用命令重构        47
3.3.1　分出模型        47
3.3.2　用命令对象包装模型        48
3.3.3　分离模型逻辑        48
3.3.4　分离返回视图        52
3.3.5　使用JSP建立返回视图        54
3.4　小结        56
3.5　本章介绍的反模式        56
第4章　JSP之苦        58
4.1　还没有结束        58
4.1.1　找出危险信号        58
4.2　反模式：整块JSP        59
4.2.1　这个程序未能做到模型-视图分离        60
4.2.2　解决方案：重构为模型-视图-控制器        61
4.3　反模式：复合JSP        62
4.3.1　该不该结合多个JSP        63
4.3.2　结合了两个界面的例子        64
4.3.3　解决方案：分解JSP        68
4.3.4　在控制器servlet中做判定        68
4.4　小反模式：过粗和过细的命令        71
4.4.1　一组中有太多的命令        72
4.4.2　解决方案：重构为合适的粒度        72
4.4.3　有关粒度的提示        73
4.5　小反模式：胖命令        74
4.6　反模式回顾        74
4.7　本章介绍的反模式        74
第5章　缓存管理之苦        77
5.1　我们需要缓存！        77
5.2　反模式：缺少缓存        79
5.2.1　没有缓存的糟糕BBS        79
5.2.2　构建ShowBoard的模型、视图和控制器        80
5.2.3　构建ShowThread的模型、视图和控制器        82
5.2.4　构建AddPost的模型、视图和控制器        86
5.2.5　性能问题        91
5.3　解决方案：缓存        91
5.3.1　解决方案1：使用一个硬件缓存        92
5.3.2　解决方案2：缓存命令        92
5.3.3　为BBS增加缓存        93
5.3.4　对缓存命令的改进        97
5.4　与缓存有关的小反模式        99
5.4.1　对静态缓存的并发访问        99
5.4.2　不断膨胀的缓存        99
5.5　反模式：同步读/写瓶颈        99
5.5.1　读者之间的冲突会降低性能        100
5.5.2　读/写锁允许正确地共享访问        101
5.6　消除无缓存反模式        102
5.7　本章介绍的反模式        103
第6章　内存之苦        105
6.1　了解内存泄漏和反模式        105
6.1.1　管理内存        106
6.1.2　理解垃圾回收        106
6.1.3　引用计数        107
6.1.4　可达对象        108
6.2　C++换Java        109
6.2.1　导致Java内存泄漏的情况        109
6.2.2　找出Java的内存泄漏        109
6.3　反模式：流失监听者泄漏        110
6.3.1　分析一些危险的做法        111
6.3.2　解决方案1：显式地删除监听者        113
6.3.3　解决方案2：缩短锚的生命周期        114
6.3.4　解决方案3：弱化引用        114
6.3.5　引用对象可以简化内存管理        115
6.4　反模式：泄漏集合        115
6.4.1　由于缓存和会话状态导致的问题        116
6.4.2　解决方案1：搜索常见的警告信号        116
6.4.3　解决方案2：让增加/删除调用匹配        117
6.4.4　解决方案3：使用软引用完成缓存        117
6.4.5　解决方案4：使用带弱引用的集合        118
6.4.6　解决方案5：使用finally        118
6.5　解决内存泄漏        118
6.5.1　确信存在泄漏        118
6.5.2　确定泄漏应当得到修正        119
6.5.3　隔离问题        120
6.5.4　确定根源，修正问题        120
6.5.5　防止将来出现同样的问题        121
6.6　小反模式：小肥猪        121
6.6.1　串管理        122
6.6.2　集合        122
6.6.3　继承链        123
6.7　小结        123
6.8　本章介绍的反模式        123
第7章　连接和耦合之苦        125
7.1　建立连接        125
7.2　反模式：连接抖动        125
7.2.1　对每个访问都创建和终止连接        126
7.2.2　解决方案：利用池来重用连接        127
7.2.3　重构BBS例子，增加入池连接        129
7.2.4　使用getPooledConnection        130
7.2.5　使用J2EE连接器体系结构        131
7.3　反模式：分离清洁器        132
7.3.1　异常可能导致分离清洁器        133
7.3.2　解决方案：在finally中让连接与清理配对        134
7.4　反模式：捆绑的连接        135
7.4.1　通信缓冲区        136
7.4.2　过早绑定        138
7.4.3　解决方案1：利用XML消息解耦合        138
7.4.4　解决方案2：利用Web服务延迟绑定        139
7.5　关于XML误用的小反模式        140
7.5.1　XML金榔头        140
7.5.2　XML转换之苦        141
7.6　小反模式：严格XML        142
7.6.1　命名冲突        142
7.6.2　严格构造        144
7.6.3　限制性的可变内容容器        145
7.6.4　XML版本问题        147
7.7　小结：苦连接变甜        148
7.8　本章介绍的反模式        148
第8章　bean之苦        151
8.1　Enterprise JavaBeans简要回顾        151
8.1.1　基于组件的分布式体系结构        152
8.1.2　EJB的类型        152
8.2　利用EJB实现的糟糕BBS        153
8.2.1　EJB应用中的元素        154
8.2.2　构建远程接口        155
8.2.3　创建home接口        156
8.2.4　实现bean类        158
8.2.5　定义主键        162
8.2.6　创建部署描述文件        163
8.2.7　使用模型        165
8.3　反模式：往返通信        165
8.3.1　计算分布式部署的开销        166
8.3.2　会话太多的接口        167
8.3.3　解决方案：利用外观组合往返通信        168
8.3.4　往返通信的根源        169
8.3.5　利用外观重构BBS        169
8.4　反模式：张冠李戴        175
8.4.1　小反模式：bean托管连接        175
8.4.2　解决方案：视图、映射器、bean托管连接        176
8.4.3　小反模式：实体bean只是完成一些轻量级的功能        176
8.4.4　小反模式：实体bean仅用于读        177
8.4.5　小反模式：实体bean仅用于写而不读        177
8.4.6　麻烦的可滚动列表        177
8.4.7　总解决方案：选择合适的bean完成合适的任务        178
8.5　小反模式：一切都是EJB        178
8.6　EJB和缓存        179
8.6.1　利用外观实现缓存        179
8.7　消除苦bean        180
8.8　本章介绍的反模式        180
第三部分　全  景  图
第9章　卫生之苦        184
9.1　为什么要研究编程卫生        184
9.1.1　极限编程需要好的编程卫生        185
9.1.2　编码标准可以避免反模式        185
9.2　小反模式：不可达的代码        186
9.2.1　名字匹配        186
9.2.2　命名标准        187
9.2.3　大括号和缩进        190
9.2.4　注释        191
9.2.5　制表符和空格        194
9.2.6　编辑器        194
9.3　小反模式：组织和可见性        195
9.4　小反模式：结构        198
9.4.1　基本面向对象理论        198
9.4.2　低级设计因素        198
9.4.3　异常        200
9.5　小反模式：泄漏和性能        200
9.6　测试的约定        201
9.7　建立一个好的风格指南        202
9.7.1　是买、是借还是偷？        202
9.7.2　Contextual公司的一个示例风格指南        203
9.8　编码标准小结        205
第10章　可扩展性之苦        208
10.1　保证性能的好拓扑        208
10.1.1　同构组中的硬件分层        210
10.1.2　其他拓扑变种        211
10.2　反模式：事后再考虑性能        212
10.2.1　开发时不做性能规划        213
10.2.2　一些真实世界的例子        213
10.2.3　解决方案：做性能规划！        214
10.3　反模式：往返通信        216
10.3.1　解决方案：缓存和外观        216
10.4　反模式：不好的负载管理        217
10.4.1　解决方案：工作负载管理        219
10.4.2　真正的负载平衡        220
10.5　反模式：混乱的会话管理        221
10.5.1　解决方案1：利用会话亲缘性分派        221
10.5.2　解决方案2：使用一个分布式状态管理服务        221
10.5.3　使用定制会话bean解决方案        222
10.5.4　使用定制实体bean解决方案        222
10.6　反模式：抖动调优        222
10.6.1　解决方案：使用合理的性能改进方法        223
10.7　驯服性能野兽        224
10.8　本章介绍的反模式        224
第11章　圆满的告别        227
11.1　反模式可以在很多层次上提供帮助        227
11.1.1　反模式促进职业发展        228
11.1.2　了解反模式可以改善程序        228
11.1.3　了解反模式可以使你成为一个更好的程序员        228
11.2　在过程中集成反模式        229
11.3　更上一层楼        230
附录A　反模式参照表        232
参考文献        238