编写高质量代码:改善Java程序的151个建议(第10章:性能和效率，第11章:开源世界，第12章:思想为源___建议132~151)

第10章:性能和效率

建议132：提高Java性能的基本方法

建议133：若非必要，不要克隆对象

建议134：推荐使用“望闻问切”的方式诊断性能

建议135：必须定义性能衡量标准

建议136：枪打出头鸟--解决首要系统性能问题

建议137：调整JVM参数以提升性能

建议138：性能是个大“咕咚”

第11章：开源世界

建议139：大胆采用开源工具

建议140：推荐使用Guava扩展工具包

建议141：Apache工具包

建议142：推荐使用Joda日期扩展包

建议143：能够选择多种Collection扩展

第十二章：思想为源

建议144：提倡良好的代码风格

建议145：不要彻底依靠单元测试来发现问题

建议146：让注释正确、清晰、简洁

建议147：让接口的职责保持单一

建议148：加强类的可替换性

建议149：依赖抽象而不是实现

建议150：抛弃七条不良的编码习惯

建议151：以技术员自律而不是工人

第10章:性能和效率

建议132：提高Java性能的基本方法

JAVA性能优化：35个小细节让你提高java代码的运行效率

建议133：若非必要，不要克隆对象

JVM对new进行了大量的性能优化，而clone方式只是一个冷僻的生成对象方式，并非主流，它主要用于构造函数比较复杂，对象属性比较多，经过new关键字建立一个对象比较耗时间的时候。

建议134：推荐使用“望闻问切”的方式诊断性能

一、望

性能问题从表象上能够分为两类：

① 较难重现的偶发性问题

② 可重现的性能问题

二、闻

在性能优化上的“闻”则是关注项目被动产生的信息，其中包括：项目组的技术能力（主要取决于技术经理的技术能力）、文化氛围、群体的习惯和习性，以及他们专一和擅长的领域等。
@若是项目组的技术能力很强，有资深的数据库专家，有顶尖的架构师，也有首席程序员，那性能问题产生的根源就应该定位在无心识的代码缺陷上。
@若是项目组的文化氛围很糟糕，组员不交流，没有固定的代码规范，缺少总体的架构等，那性能问题的根源就可能存在于某个配置上，或者相互的接口调用上。
@若是项目组已经习惯了某一个框架，并且也习惯了框架的种种约束，那性能的根源就多是有人越过了框架的协约。

三、问

与技术人员和业务人员一块儿探讨问题，了解性能问题的历史情况。

四、切

看设计，看代码，看日志，看系统环境，而后是思考分析，最后给出结论。

建议135：必须定义性能衡量标准

出现性能问题不可怕，可怕的是没有目标。

一、核心业务的响应时间

二、重要业务的响应时间

性能衡量标准必须在必定的环境下，好比网络、操做系统、硬件设备等肯定的状况下才会有意义，而且还须要限定并发数、资源数（如10万数据和1000万的数据响应时间确定不一样）等。

建议136：枪打出头鸟--解决首要系统性能问题

解决性能问题时，不要把全部的问题都摆在眼前，这只会“扰乱”你的思惟，集中精力，找到那个“出头鸟”，解决它，在大部分状况下，一批性能问题都会迎刃而解，并且咱们的用户关注最多的可能就是系统20%的功能，可能咱们解决了这一部分，已经达到了用户的预期目标，也就标志着咱们的优化工做能够结束了。

建议137：调整JVM参数以提升性能

一、调整堆内存大小

二、调整堆内存中各分区的比例

三、变动GC的垃圾回收策略

四、更换JVM

注意点：
metaSpace在jdk1.7以前被称为Permanent Space
并且严格意义上讲metaSpace不属于堆空间
见下图：

关于部分调优项的介绍

建议138：性能是个大“咕咚”

一、没有慢的系统，只有不知足业务的系统
二、没有慢的系统，只有架构不良的系统
三、没有慢的系统，只有懒惰的技术人员
四、没有慢的系统，只有不肯意投入的系统

第11章：开源世界

建议139：大胆采用开源工具

在选择开源工具和框架时要遵循必定的原则：

一、普适性原则

确保大部分项目成员对工具都比较熟悉

二、惟一性原则

相同的工具只选择一个或一种，不要让多种相同或类似职能的工具共存。
例如集合工具能够在Apache Commons的collections包和Google Guava的Collections工具包中二选其一。

三、用比较有名的开源工具

四、精而专原则

好比虽然Spring框架提供了Utils工具包，但在通常状况下不要使用它，由于它不专，Utils工具包只是Spring框架中的一个附加功能而已，要用就用Apache Commons的BeanUtils、Lang等工具包。

五、高热度原则

一个开源项目的热度越高，更新得就越频繁，使用的人群就越广，Bug的曝光率就越快，修复效率也就越高。

建议140：推荐使用Guava扩展工具包

建议141：Apache工具包

建议142：推荐使用Joda日期扩展包

一、本地格式的日期时间

二、日期计算

三、时区时间

四、能够与JDK的日期库方便地进行转换

建议143：能够选择多种Collection扩展

三个比较有个性的Collections扩展工具包：

一、fastutil

主要提供了两种功能：一种是限定键值类型（Type Specific）的Map、List、Set等，另外一种是大容量的集合。

二、Trove

提供了一个快速、高效、低内存消耗的Collections集合，而且还提供了过滤和拦截的功能，同时还提供了基本类型的集合。

Trove的最大优点在于高性能上，在进行通常的增长、修改、删除操做时，Trove的响应时间比JDK的集合少了一个数量级，比fastutil也会高不少，所以在高性能项目中药考虑使用Trove。

三、lambdaj

lambdaj是一个纯净的集合操做工具，他不会提供任何的集合扩展，只会提供集合的操做，好比查询、过滤、统一初始化等，特别是它的查询操做，会提供求和、求平均值的方法：

List＜Integer＞ints=new ArrayList＜Integer＞();
//计算平均值
Lambda.avg（ints）;
//统计每一个元素出现的次数，返回的是一个Map
Lambda.count（ints）；
//按照年龄排序
List＜Person＞persons=new ArrayList＜Person＞();
Lambda.sort（persons, Lambda.on（Person.class）.getAge()));
//串联全部元素的指定属性，输出为：张三，李四，王五
Lambda.joinFrom（persons）.getName();
//过滤出年龄大于20岁的所用元素，输出为一个子列表
Lambda.select（persons, new BaseMatcher＜Person＞(){
@Override
public boolean matches（Object_person）{
Person p=（Person）_person；
return p.getAge（）＞20；
}
public void describeTo（Description desc）{
}
});
//查找出最大年龄
Lambda.maxFrom（persons）.getAge();
//抽取出全部姓名造成一个数组
Lambda.extract（persons, Lambda.on（Person.class）.getName()));

第十二章：思想为源

建议144：提倡良好的代码风格

一、整洁

二、统一

三、流行

四、便捷

建议145：不要彻底依靠单元测试来发现问题

一、单元测试不可能测试全部的场景（路径）
单元测试必须测试的三种数据场景是：正常场景、边界场景、异常场景。若是要进行完整的测试就必须创建三个不一样的测试场景：正常数据场景，用来测试代码的主逻辑；边界数据场景，用来测试代码（或数据）在边界的状况下逻辑是否正确；异常数据场景，用来测试出现异常非故障时可否按照预期运行。
一般在项目中，单元测试覆盖率很难达到60%，由于不能100%覆盖，这就致使了代码测试的不完整性，隐藏的缺陷也就必然存在了。
二、代码整合错误是不可避免的

三、部分代码没法测试

四、单元测试验证的是编码人员的假设

建议146：让注释正确、清晰、简洁

提倡好的注释：
一、法律版权信息
二、解释意图的注释
说明为何要这样作，而不是怎么作的，好比解决了哪一个Bug，方法过期的缘由是什么。
三、警示性注释
四、TODO注释

建议147：让接口的职责保持单一

单一职责有如下三个优势：
一、类的复杂性下降
二、可读性和可维护性提升
三、下降变动风险

建议148：加强类的可替换性

里氏替换原则：全部引用基类的地方必须能透明地使用其子类的对象。

建议149：依赖抽象而不是实现

依赖倒置原则（Dependence Inversion Principle，简称DIP）:
高层模块不该该依赖低层模块，二者都应该依赖其抽象。
抽象不该该依赖细节。
细节应该依赖抽象。

要作到遵循此原则要作到如下几点：
（1）尽可能抽象
接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
（2）表面类型必须是抽象的
好比定义集合，尽可能使用：
List＜String＞list=new ArrayList＜String＞（）；
（3）任何类都不该该从具体类派生
开发阶段要作到这一点，但不是绝对的，尤为是在维护时。
（4）尽可能不要覆写基类的方法
（5）抽象不关注细节

建议150：抛弃七条不良的编码习惯

一、自由格式的代码

二、不使用抽象的代码

三、彰显个性的代码

四、死代码

五、冗余的代码

六、拒绝变化的代码

七、自觉得是的代码

建议151：以技术员自律而不是工人

一、熟悉工具

二、使用IDE

三、坚持编码

四、编码前思考

五、坚持重构

六、多写文档

七、保持程序版本的简单性

八、作好备份

九、作单元测试

十、不要重复发明轮子

十一、不要拷贝

十二、让代码充满灵性

1三、测试自动化

1四、作压力测试

1五、“剽窃”不可耻

多看开源代码

1六、坚持向敏捷学习

1七、分享

1八、刨根问底

1九、横向扩展

Java要运行在JVM、操做系统上，同时还要与硬件、网络、存储交互，另外要遵循诸如FTP、SMTP、HTTP等协议，还要实现Web Service、RMI、XML-RPC等接口，因此咱们必须熟悉相关的知识—扩展知识面，这些都是必须去学习的。

 

编写高质量代码：改善Java程序的151个建议@目录