本书是一本关于Java最佳实践的集大成之作，它从Java语言本身、Java程序的架构设计和思想、Java程序的编码规范和习惯等方面对151个经典的问题给出了解决方案，为Java开发者提高开发效率和编写高质量的Java代码提供了宝贵的建议。
从语法、程序设计和架构、工具和框架、编码风格、编程思想5个方面深入探讨编写高质量Java代码的技巧、禁忌和最佳实践
编写高质量代码
改善Java程序的151个建议
秦小波 著
封底：
是一本关于Java编码最佳实践的集大成之作，也是一本能指导Java程序员编写出高质量代码的指点迷津之作。全书从Java语法、程序的架构和设计、编码规范和编程习惯等方面为广大的Java程序员们总结出了151条极富借鉴意义的建议，这些建议都在实践中被证明是解决Java编码中疑难问题的最佳实践。如果能掌握本书中的内容，不仅能加深对Java语言的理解，还能提升程序架构和设计方面的能力，同时还能规范我们的开发行为和习惯，让我们成为优秀的程序员，编写出更高质量的代码。
—— 51CTO（www.51cto.com，中国领先的IT技术网站）
Coding为我们创造了一个丰富多彩的虚拟世界，本书是作者秦小波多年工作经验的总结，也许能为所有从事Java软件开发的同行们提供有益的参考。本书除了与大家分享了151条编写高质量Java代码的宝贵建议之外，它还在试图告诉创造虚拟世界的程序员们，Coding不仅仅是使用智慧，更多的是对它的热爱，唯有热爱和用心才能编写出高质量的代码，才能开发出优秀的应用。
—— 李海宁 交通银行软件开发中心总经理
本书有几个很突出的特点：第一，内容实用，它没有去讲解基本语法，那是大学教科书的内容，本书着重探讨了如何才能将Java代码编写得更高效、更优雅；第二，涉及面广，从语法到编程规范和编程思想，从JDK API到开源框架，都有所涉猎；第三，注重实战，书中的所有建议都是从实践中总结出来的，都是真实场景的重现，不是纸上谈兵。除此之外，本书内容精炼、语言幽默、通俗流畅，阅读体验十分好。对于正在进阶修炼途中的Java程序员来说，本书是提高开发技能和自身修养的好帮手。
—— 计文柯 资深Java技术专家，
著有畅销书《Spring技术内幕：深入解析Spring架构与设计原理》
前：
大多数Java程序员都会在前进的道路上被以下几类问题所困扰：
一、来自于语言本身的问题。例如：
覆写变长方法为什么会出现不能编译的情况？
final修饰的int类型常量竟然在运行期被修改？
匿名类是否有构造函数？它与普通类的构造函数有何不同？
为什么要把受检异常转化为非受检异常？
……
二、来自于程序设计和常用API的问题。例如：
如何用一行代码实现两个集合的交、差、并集？
如何才能动态加载一个类？数组如何动态加载？
在switch中使用枚举类型，为什么会出现NullPointerException异常？
为什么使用了volatile关键字后数据还是出现混乱？
显式锁（Lock类）和内部锁（synchronized关键字）完全一样吗？
……
三、来自于程序架构和思想方面的问题。例如：
Java的性能是否曾经让你担忧过？或者曾经让你很受伤？
到底是该多采用开源工具还是自己写工具类？若采用开源工具，有什么评测标准？
什么样的代码风格才是优秀的？怎么才能让一个团队保持同样的风格？
……
如果你曾经为诸如此类的问题感到疑惑不解或顿然大悟，说明你正在向Java技术的巅峰攀登，正在成长为“振臂一呼，应者云集”的技术大牛，恭喜你！本书从不同的侧面出发，对Java编码中各种棘手的疑难杂症和常见问题奉献了真知灼见，相信你一定能从中受益。
作者简介
秦小波 资深软件开发工程师、系统分析师和架构师（获Sun架构师认证），从事软件开发工作10余年，实践经验极其丰富。资深Java技术专家，精通Java语言、Spring、Struts 2、Hibernate、iBatis、jBPM等Java技术，在企业级Java应用领域积累了大量工程经验，对ESB、BPEL等整合技术也有较深入的认识。精通设计模式，对设计模式有深刻的认识和独到见解，而且创造性地提出了自己在大量实践中总结出来的新的设计模式。他撰写的《设计模式之禅》一书凭借优质的内容和良好的可读性广获读者好评，被誉为“设计模式领域的里程碑之作”。此外，他还是一位优秀的DBA，获IBM DB2 DBA资格认证，对海量数据处理有深入的研究。
从决定撰写本书到完稿历时9个月，期间曾经遇到过种种困难和挫折，但这个过程让我明白了坚持的意义，明白了“行百里者半九十”的寓意—坚持下去，终于到了写前言的时刻。
为什么写这本书
从第一次敲出“Hello World”到现在已经有15年时间了，在这15年里，我当过程序员和架构师，也担任过项目经理和技术顾问—基本上与技术沾边的事情都做过。从第一次接触Java到现在,已经有11年4个月了,在这些年里，我对Java可谓是情有独钟，对其编程思想、开源产品、商业产品、趣闻轶事、风流人物等都有所了解和研究。对于Java，我非常感激，从物质上来说，它给了我工作，帮助我养家糊口；从精神上来说，它带给我无数的喜悦、困惑、痛苦和无奈— 一如我们的生活。
我不是技术高手，只是技术领域的一个拓荒者，我希望能把自己的知识和经验贡献出来，以飨读者。在写作的过程中，我也反复地思考：我为谁而写这本书？为什么要写？
希望本书能帮您少走弯路
您是否曾经为了提供一个“One Line”的解决方案而彻夜地查看源代码？现在您不用了。
您是否曾经为了理解某个算法而冥思苦想、阅览群书？现在您不用了。
您是否曾经为了提升0.1秒的性能而对N种实现方案进行严格测试和对比？现在您不用了。
您是否曾经为了避免多线程死锁问题而遍寻高手共同诊治？现在您不用了。
……
在学习和使用Java的过程中您是否在原本可以很快掌握或解决的问题上耗费了大量的时间和精力？也许您现在不用了，本书的很多内容都是我用曾经付出的代价换来的，希望它能帮助您少走弯路！
希望本书能帮您打牢基础
那些所谓的架构师、设计师、项目经理、分析师们，已经有多长时间没有写过代码了？代码是一切的基石，我不太信任连“Hello World”都没有写过的架构师。看看我们软件界的先辈们吧，Dennis M. Ritchie决定创造一门“看上去很好”的语言时，如果只是站在高处呐喊，这门语言是划时代的，它有多么优秀，但不去实现，又有何用呢？没有Dennis M. Ritchie的亲自编码实现，C语言不可能诞生，UNIX操作系统也不可能诞生。Linux在聚拢成千上万的开源狂热者对它进行开发和扩展之前，如果没有Linus的编码实现，仅凭他高声呐喊“我要创造一个划时代的操作系统”，有用吗？一切的一切都是以编码实现为前提的，代码是我们前进的基石。
这是一个英雄辈出的年代，我们每个人都希望自己被顶礼膜拜，可是这需要资本和实力，而我们的实力体现了我们处理技术问题的能力：
你能写出简单、清晰、高效的代码？——Show it!
你能架构一个稳定、健壮、快捷的系统？——Do it!
你能回答一个困扰N多人的问题？——Answer it!
你能修复一个系统Bug？ ——Fix it!
你非常熟悉某个开源产品？——Broadcast it!
你能提升系统性能？——Tune it!
……
但是，“工欲善其事，必先利其器”，在“善其事”之前，先看看我们的“器”是否已经磨得足够锋利了，是否能够在我们前进的路上披荆斩棘。无论您将来的职业发展方向是架构师、设计师、分析师、管理者，还是其他职位，只要您还与软件打交道，您就有必要打好技术基础。本书对核心的Java编程技术进行了凝练，如果能全部理解并付诸实践，您的基础一定会更加牢固。
希望本书能帮您打造一支技术战斗力强的团队
在您的团队中是否出现过以下现象：
没有人愿意听一场关于编码奥秘的讲座，他们觉得这是浪费时间；
没有人愿意去思考和探究一个算法，他们觉得这实在是多余，Google完全可以解决；
没有人愿意主动重构一段代码，他们觉得新任务已经堆积成山了，“没有坏，就不要去修它”；
没有人愿意格式化一下代码，即便只需要按一下【Ctrl+Shift+F】快捷键，他们觉得代码写完就完了，何必再去温习；
没有人愿意花时间去深究一下开源框架，他们觉得够用就好；
……
一支有实力的软件研发团队是建立在技术的基础之上的，团队成员之间需要经常地互相交流和切磋，尤其是基于可辨别、可理解的编码问题。不可否认，概念和思想也很重要，但我更看重基于代码的交流，因为代码不会说谎，比如SOA，10个人至少会有5个答案，但代码就不同了，同样的代码，结果只有一个，要么是错的，要么是对的，这才是一个技术团队应该有的氛围。本书中提出的这些问题绝大部分可能都是您的团队成员在日常的开发中会遇到的，我针对这些问题给出的建议不是唯一的解决方案，也许您的团队在讨论这一个个问题的时候能有更好的解决办法。希望通过对本书中的这些问题的争辩、讨论和实践能全面提升每一位团队成员的技术实力，从而增强整个团队的战斗力！
本书特色
深。本书不是一本语法书，它不会教您怎么编写Java代码，但是它会告诉您，为什么StringBuilder会比String类效率高，HashMap的自增是如何实现的，为什么并行计算一般都是从Executors开始的……不仅仅告诉您How（怎么做），而且还告诉您Why（为什么要这样做）。
广。涉及面广，从编码规则到编程思想，从基本语法到系统框架，从JDK API到开源产品，全部都有涉猎，而且所有的建议都不是纸上谈兵，都与真实的场景相结合。
点。讲解一个知识点，而不是一个知识面，比如多线程，这里不提供多线程的解决方案，而是告诉您如何安全地停止一个线程，如何设置多线程关卡，什么时候该用lock，什么时候该用synchronize，等等。
精。简明扼要，直捣黄龙，一个建议就是对一个问题的解释和说明，以及提出相关的解决方案，不拖泥带水，只针对一个知识点进行讲解。
畅。本书延续了我一贯的写作风格，行云流水，娓娓道来，每次想好了一个主题后，都会先打一个腹稿，思考如何讲才能更流畅。本书不是一本很无趣的书，我一直想把它写得生动和优雅，但Code就是Code，很多时候容不得深加工，最直接也就是最简洁的。
这是一本建议书，想想看，在您写代码的时候，有这样一本书籍在您的手边，告诉您如何才能编写出优雅而高效的代码，那将是一件多么惬意的事情啊！
本书面向的读者
寻找“One Line”（一行）解决方案的编码人员。
希望提升自己编码能力的程序员。
期望能够在开源世界仗剑而行的有志之士。
对编码痴情的人。
总之，只要还在Java圈子里混就有必要阅读本书，不管是程序员、测试人员、分析师、架构师，还是项目经理，都有必要。
如何阅读本书
首先声明，本书不是面向初级Java程序员的，在阅读本书之前至少要对基本的Java语法有初步了解，最好是参与过几个项目，写过一些代码，具备了这些条件，阅读本书才会有更大的收获，才会觉得是一种享受。
本书的各个章节和各个建议都是相对独立的，所以，您可以从任何章节的任何建议开始阅读。强烈建议您将它放在办公桌旁，遇到问题时随手翻阅。
本书附带有大量的源码（下载地址见华章网站www.hzbook.com）,建议大家在阅读本书时拷贝书中的示例代码，放到自己的收藏夹中，以备需要时使用。
勘误与支持
首先，我要为书中可能出现的错别字、多意句、歧义句、代码缺陷等错误向您真诚地道歉。虽然杨福川、杨绣国两位编辑和我都为此书付出了非常大的努力，但可能还是会有一些瑕疵，如果你在阅读本书时发现错误或有问题想一起讨论，请发邮件（cbf4life@126.com）给我，我会尽快给您回复。
本书的所有勘误，我都会发表在我的个人博客（http://cbf4life.iteye.com/）上。
致谢
首先，感谢杨福川和杨绣国两位编辑，在他们的编审下，本书才有了一个质的飞跃，没有他们的计划和安排，本书不可能出版。
其次，感谢家人的支持，为了写这本书，用尽了全部的休息时间，很少有时间陪伴父母和妻儿，甚至连吃一顿团圆饭都成了奢望，他们的大力支持让我信心满怀、干劲十足。儿子已经6岁了，明白骑在爸爸身上是对爸爸的折磨，也知道玩具是可以从网上买到的，“爸爸，给我买一个变形金刚……你在网上查呀……今天一定要买……”儿子在不知不觉中长大了。
再次，感谢交通银行“531”工程的所有领导和同事，是他们让我在这样超大规模的工程中学习和成长，使自己的技术和技能有了长足的进步；感谢我的领导李海宁总经理和周云康高级经理，他们时时迸发出的闪光智慧让我受益匪浅；感谢软件开发中心所有同仁对我的帮助和鼓励！
最后，感谢我的朋友王骢，他无偿地把钥匙给我，让我有一个安静的地方思考和写作，有这样的朋友，人生无憾！
当然，还要感谢您，感谢您对本书的关注。
再次对本书中可能出现的错误表示歉意，真诚地接受大家的“轰炸”！
秦小波
2011年8月于上海
计算机\程序设计
CODING为我们创造了一个色彩斑斓的虚拟世界，秦小波的这本书，通过自己的实践和用心为所有从事JAVA CODING的同行们提供了一个有益的参考，同时也告诉创造虚拟世界的人们，CODING不仅仅是使用智慧，更多的是对它的热爱，唯有热爱和用心才能将虚拟的世界造就的更加绚丽多彩，这本书将使你的造就之路走的更加地顺利。
交通银行软件开发中心总经理 李海宁
秦小波 著：暂无简介
前 言
第1章 Java开发中通用的方法和准则/1
建议1： 不要在常量和变量中出现易混淆的字母/2
建议2： 莫让常量蜕变成变量/2
建议3： 三元操作符的类型务必一致/3
建议4： 避免带有变长参数的方法重载/4
建议5： 别让null值和空值威胁到变长方法/6
建议6： 覆写变长方法也循规蹈矩/7
建议7： 警惕自增的陷阱/8
建议8： 不要让旧语法困扰你/10
建议9： 少用静态导入/11
建议10： 不要在本类中覆盖静态导入的变量和方法/13
建议11： 养成良好习惯，显式声明UID/14
建议12： 避免用序列化类在构造函数中为不变量赋值/17
建议13： 避免为final变量复杂赋值/19
建议14： 使用序列化类的私有方法巧妙解决部分属性持久化问题/20
建议15： break万万不可忘/23
建议16： 易变业务使用脚本语言编写/25
建议17： 慎用动态编译/27
建议18： 避免instanceof非预期结果/29
建议19： 断言绝对不是鸡肋/31
建议20： 不要只替换一个类/33
第2章 基本类型/35
建议21： 用偶判断，不用奇判断/36
建议22： 用整数类型处理货币/37
建议23： 不要让类型默默转换/38
建议24： 边界，边界，还是边界/39
建议25： 不要让四舍五入亏了一方/41
建议26： 提防包装类型的null值/43
建议27： 谨慎包装类型的大小比较/45
建议28： 优先使用整型池/46
建议29： 优先选择基本类型/48
建议30： 不要随便设置随机种子/49
第3章 类、对象及方法/52
建议31： 在接口中不要存在实现代码/53
建议32： 静态变量一定要先声明后赋值/54
建议33： 不要覆写静态方法/55
建议34： 构造函数尽量简化/57
建议35： 避免在构造函数中初始化其他类/58
建议36： 使用构造代码块精炼程序/60
建议37： 构造代码块会想你所想/61
建议38： 使用静态内部类提高封装性/63
建议39： 使用匿名类的构造函数/65
建议40： 匿名类的构造函数很特殊/66
建议41： 让多重继承成为现实/68
建议42： 让工具类不可实例化/70
建议43： 避免对象的浅拷贝/71
建议44： 推荐使用序列化实现对象的拷贝/73
建议45： 覆写equals方法时不要识别不出自己/74
建议46： equals应该考虑null值情景/76
建议47： 在equals中使用getClass进行类型判断/77
建议48： 覆写equals方法必须覆写hashCode方法/78
建议49： 推荐覆写toString方法/80
建议50： 使用package-info类为包服务/81
建议51： 不要主动进行垃圾回收/82
第4章 字符串/83
建议52： 推荐使用String直接量赋值/84
建议53： 注意方法中传递的参数要求/85
建议54： 正确使用String、StringBuffer、StringBuilder/86
建议55： 注意字符串的位置/87
建议56： 自由选择字符串拼接方法/88
建议57： 推荐在复杂字符串操作中使用正则表达式/90
建议58： 强烈建议使用UTF编码/92
建议59： 对字符串排序持一种宽容的心态/94
第5章 数组和集合/97
建议60： 性能考虑，数组是首选/98
建议61： 若有必要，使用变长数组/99
建议62： 警惕数组的浅拷贝/100
建议63： 在明确的场景下，为集合指定初始容量/101
建议64： 多种最值算法，适时选择/104
建议65： 避开基本类型数组转换列表陷阱/105
建议66： asList方法产生的List对象不可更改/107
建议67： 不同的列表选择不同的遍历方法/108
建议68： 频繁插入和删除时使用LinkedList/112
建议69： 列表相等只需关心元素数据/115
建议70：子列表只是原列表的一个视图/117
建议71： 推荐使用subList处理局部列表/119
建议72： 生成子列表后不要再操作原列表/120
建议73： 使用Comparator进行排序/122
建议74： 不推荐使用binarySearch对列表进行检索/125
建议75： 集合中的元素必须做到compareTo和equals同步/127
建议76： 集合运算时使用更优雅的方式/129
建议77： 使用shuffle打乱列表/131
建议78： 减少HashMap中元素的数量/132
建议79： 集合中的哈希码不要重复/135
建议80： 多线程使用Vector或HashTable/139
建议81： 非稳定排序推荐使用List/141
建议82： 由点及面，一叶知秋—集合大家族/143
第6章 枚举和注解/145
建议83： 推荐使用枚举定义常量/146
建议84： 使用构造函数协助描述枚举项/149
建议85： 小心switch带来的空值异常/150
建议86： 在switch的default代码块中增加AssertionError错误/152
建议87： 使用valueOf前必须进行校验/152
建议88： 用枚举实现工厂方法模式更简洁/155
建议89： 枚举项的数量限制在64个以内/157
建议90： 小心注解继承/160
建议91： 枚举和注解结合使用威力更大/162
建议92： 注意@Override不同版本的区别/164
第7章 泛型和反射/166
建议93： Java的泛型是类型擦除的/167
建议94： 不能初始化泛型参数和数组/169
建议95： 强制声明泛型的实际类型/170
建议96： 不同的场景使用不同的泛型通配符/172
建议97： 警惕泛型是不能协变和逆变的/174
建议98： 建议采用的顺序是List
