Effective Java笔记－－第8章

第8章

第45条：将局部变量的作用域控制在最小

1. 最有效的方法：第一次使用此局部变量的地方声明。［越晚声明越好］［降低代码出错的可能性］

2. 声明同时：进行有意义的初始化

3. 2的例外：try－catch，局部变量的初始化可能是无意义的

4. 一般情况下：for循环优于while循环［for更短］［while循环可能扩大局部变量的作用域，使得代码更容易出错］

第46条：for－each循环优于传统的for循环

参考［遍历collection］：点击打开链接 

［for-each使用例子，访问多维数组］：点击打开链接 

1. 性能上：for－each和for一样，某些情况下，for－each效率还稍微高一点

2. 优点：for－each提高代码可读性，写起来也不容易出错。尤其：多个集合嵌套迭代时候，太容易出错了，比如：访问Collection的时候，Iterator调用next()

3. 缺点：for－each只能用于读取，不能用于写。因为没有显式获取数组，Collection的index

第47条：了解和使用类库

1. 类库都是专家写的，类库会持续更新，性能会不断提升，会不断添加接口，会有大神不断的维护，基本上没有bug。类库的代码一般比自己写的好

2. 大家都在用，使得自己的代码融入主流

3. 应该保持：自己熟悉最新的类库同步

4. 应该熟悉的类库：java.lang   java.util   java.io   java.util.concurrent(并发库)

5. 不要重新发明轮子。遇到需求，先查查是否有可用的类库，实在没有的话，再考虑自己写

第48条：如果需要精确的答案，应避免使用float，double

1.  java计算：1.03-0.42＝0.6100000000000001

2. float和double没有提供完全精确的计算，尤其不适合货币计算

3. 代替方案：用int，long［使用最小单位］，BigDecimal计算

4. BigDecimal两个缺点：性能差一些，使用不方便

第49条：基本类型优于“装箱基本类型”

1. 基本类型（primitive）都有对应的引用类型（reference type），叫做：装箱基本类型（boxed primitive）

第50条：如果其他类型更合适，尽量避免使用字符串

第51条：注意字符串连接性能

1. 字符串拼接时候，StringBuilder性能秒杀String。推荐用 StringBuilder的append()

2. StringBuilder不是线程安全的，StringBuffer是线程安全的

3. 字符串拼接，String开销为 O(n*n)，StringBuilder开销是 O(n)。数目越大，性能差距越大

4. 其他解决办法：使用字符串数组，每次只处理一个，而不是将它们组合起来

5. 参考下面的代码：result = result + i; 性能很差

第52条：通过接口/父类 引用对象，可以让程序更灵活［面向接口/父类编程的思想］

1. 对于方法的参数，返回值，变量和域，都应该尽量使用接口进行声明。这样子，程序会更灵活：改变接口的具体实现类，并不需要修改程序的其他地方（可以顺利编译）。

2. List<Object> list = new ArrayList<Object>()  要优于 ArrayList<Object> list = new ArrayList<Object>() 。ps：我记得性能上似乎略为差一点？？

3. list如果使用了ArrayList的方法或者属性，则不行！

4. 改变接口的实现类的原因：新的实现类，性能更好，或者提供了额外的功能（如：线程安全）

5. To－Do：ThreadLocal类？

6. To－Do：接口和抽象类之间的区别

7. 没有合适的接口可用，则只能用类引用对象：有些类可能没有合适的接口，1.值类：String，Integer ；2.已经属于某些框架的类［框架的基本类型是类，不是接口］

8. 值类很少有多个实现，而且通常是final，很少有对应的接口

9. 总结：有没有合适的接口，很明显。没有就没得选择，乖乖用类吧

第53条：

第54条：谨慎提示用本地方法

1. 本地方法：指用本地程序设计语言（比如：C/C++）编写的特殊方法

2. 本地方法的用途（历史原因）：1. 访问特定平台，如访问注册表，文件锁    2. 访问遗留代码库，以前的C/C++的代码库，如FFMPEG  3. 提高性能  4. 关键代码的加密，如用在 android

3. 现在：用本地方法提高性能，不值得提倡［1. Java有很多类库可用，比如：访问注册表    2. VM优化越来越好］

4. 本地方法缺点：不易调试，可读性差，本地语言不是安全的，移植性降低，进入/退出本地方法的时候，是需要一定开销的

第55条：谨慎的进行优化

1. 优化弊大于利，尽量不要进行优化，尤其是不成熟的优化，不成熟的优化可能导致诸多问题

2. 程序结构的合理性，比性能更重要

3. 努力编写好的程序，而不是快的程序

4. 好的程序体现了：信息隐藏，模块化。修改某个模块，不会影响到系统的其他部分。后期优化的话，也方便

5. 性能的考虑：越早越好。设计之初就考虑。后期再优化的话，会修改系统的结构，使得结构变的不好

6. 注意系统性能的瓶颈：一般是：IO，

7. 优化的顺序：1. 算法  2. API，线路层协议，永久数据格式  3.

8. java代码和CPU执行的代码之间存在：语言沟。流传的性能优化的方法，半真半假

总结：1. 努力写好的程序，速度自然会随之而来。 2. 设计：API，线路层协议，永久数据格式的时候（json比xml快），一定要考虑性能。 3.可以借助性能解析工具，找到性能瓶颈（方法的调用次数，执行的时间等）  4. 优化做完后，最好测试一下，是否速度更快了  5. 算法的优化是效果最明显的