Effective java 中文版本阅读总结

Posted 2020-09-23

点击链接查看云笔记原文

花了半天时间,贪婪的啃读了Effective java 这本书(虽然闻名已久,但是很少看书)

翻着翻着就有种废寝忘食的感觉,下班了都留下来专门看书,后来索性带回家看了.

以下是内容总结,主要是对个人感觉有用的,有很大部分没有提及,因为水平有限,还没有来得及消化

1 引言

 

2 创建和销毁对象

# 静态工厂方法由于构造器

Boolean.valueOf(String); 几乎总是优于构造器Boolean(String);构造器每次调用的时候都会创建一个新的对象

* 对象创建比较昂贵的类

Calendar (推荐在静态代码块中实例化一次)

建立数据库连接的代价非常昂贵,(重用对象非常有意义,数据库连接池--但是会增加内存占用,还会损坏性能,又要考虑jvm回收)

 

* 静态工厂方法常用名称

valueOf ()

of()

getInstance() Singleton,该方法没有参数,返回唯一实例

newInstance() 确保每个返回的实例与其他实例都不同

getType() 工厂方法所返回对象的类型

newType() 工厂方法所返回对象的类型

 

# 延迟初始化

延迟到对象方法第一次调用才实例化,(有时候不建议这么做,会使得方法实现更加复杂,无法将性能显著提高)

 

# String s=new String("hello"); //don‘t do this !

该语句每次执行都会创建一个新的String实例,没必要! "hello"本身就是一个String实例

如果这种用法是在循环中,或者是在一个被频繁调用的方法中,就会创建成千上万不必要的String 实例

改进后的代码:

String s="hello"; 对象可以被重用

 

# 过期的对象引用--导致内存泄露

如果一个栈先是增长,然后再收缩,那么从栈中弹出来的对象将不会被当做垃圾回收,即使栈的程序不再引用这些对象,它们也不会被回收

这是因为栈内部维护着这些对象的过期引用(obsolete reference) ;所谓的过期引用是指,永远也不会再被解除的引用

 

3 对于所有对象都通用的方法

# 始终覆盖toString()方法 (通用约定: 应该是简洁已读的表现形式)

java.lang.Object 提供了toString的一个实现,但他返回的字符串并不是类的用户所希望看到的;

它包含"类的名称@散列码16进制表示法" 没有字符串"1353413xxxx" 来的简洁易懂

建议所有子类覆盖这个方法

 

4 类和接口

 

5 泛型

优先考虑泛型

列表优先于数组

利用有限制通配符,提升api灵活性

 

6 枚举和注解

注解优先于命名模式

 

7 方法

* 使用断言,检查参数有效性(本质上也不会有开销)

* 谨慎设计方法签名 (名称,过长参数列表)

* 谨慎使用可变参数

static int sum(int firstArg,int ...args){

int min=firstArg;

for(int arg:args){

}

}

* 返回0长度的数组或者集合,而不是null

客户端程序员可能会忘记处理null

对于避免开销问题,对于这种程度的性能问题担忧是不明智的,除非分析表明这个代码正是导致性能问题的来源;

return new Array[0];

* 为所有导出的api元素编写文档

 

8 通用程序设计

* 局部变量作用域最小化

较早程序设计语言(如c语言),要求局部变量声明在代码块的开头;这个习惯要改正

要使局部变量作用域最小化,应该是第一次使用的地方声明;(避免分散程序员注意力,等使用该变量时已经不记得变量类型和初始值了)

 

* for-each 循环优先于传递for循环

* 了解和使用内裤(类库)

具有算法背景的高级工程师花了大量时间设计,实现和测试,然后通过领域专家审核,确保正确

把时间花在应用程序上,而不是底层细节上;

很多人使用,被当做工业标准,促使优化,提高性能,无需做任何努力;

不要重新发明轮子,如果你做的事情十分常见,可能类库中已经提供实现

每个程序员都需要熟悉:

java.lang

java.util

java.io

 

* 需要精确答案,避免使用float和double

主要是为科学计算和工程计算设计,并没有提供完全精确的结果

 

* 基本类型优于集装箱类型

* 字符串连接性能

使用stringBuilder 提升50倍+ 以上

* 通过接口引用对象

规则1: 不要进行优化,

规则2: 还是不要进行优化

在没有绝对清晰的优化方案前,请不要进行优化

 

* 遵守普遍接受命名规则

* 尽量减少反射的使用

丧失了编译时检查类型的好处;

执行反射的代码非常冗长和笨拙;

性能损失,反射比普通方法调用慢了许多,差异难说 2-50倍...

RPC 远程调用时使用是比较合适的

 

 

9 异常

不太理解...

 

10 并发

* 避免过度同步(性能降低,死锁)

* executor和task优先于线程

 

11 序列化

不太理解...