首页 > 代码库 > Effective java 中文版本阅读总结

Effective java 中文版本阅读总结

2024-10-09 23:46:02   217人阅读

点击链接查看云笔记原文
花了半天时间,贪婪的啃读了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 序列化
不太理解...
 

Effective java 中文版本阅读总结


联系
我们