effective java

第一条：
内容：静态工厂替代构造函数
例子：String.valueOf() getInstance()等
静态工厂方法优点：
1,可以随意起名字，更好的描述返回对象
2,每次调用的时候不一定要创建一个新对象
3,可以返回一个原返回类型的子类型对象
静态工厂方法的缺点：
1,如果类没有公有或者受保护的构造函数就不能被子类化
2,不符合规范，破坏规范。在API文档中不会被那么明确的标识出来。

第二条：使用私有构造函数强化单态
单态的模式大家都知道了，但是使用单态的时候记住要使用私有的构造函数。
原因很简单，如果不如此很难保证单态。只要new一下另一个对象就生成了

第三条：有些类是不能实例化的，如果你要做到这点，记得使用私有的构造函数。
例如：java.util.Collections java.lang.Math 等

第四条：避免创造重复的对象
特别是这样的代码不要写： String str = new String("a string");
因为这样每次执行的时候都创建了一个"a string"对象。
可以写成这样：String str = "a string ";
另外顺便说一句，这个时候你再次定义String str2 = "a string";会复用上边的字符串.

第五条：在有些情况下手动消除对象的引用

public class Stack{
private Object[] elements;
private int size = 0;
public Stack(int initialCapacity){
this.elements = new Object[initialCapacity];
}
public void push(Object e){
ensureCapacity();
elements[size++] = e;
}
public Object pop(){
if (size == 0)
throw new EmptyStackException();
return elements[--size];
}
private void ensureCapacity(){
if (elements.length == size){
Object[] oldElements = elements;
elements = new Object[2*element.length+1];
System.arraycopy(oldElements,0,elements,0,size);
}
}
}
如果这个Stack先大量增长，然后收缩，然后在比较小的范围内使用，必定造成大量的不可回收的对象，造成内存泄漏.。
解决办法：改造一下pop()方法

public Object pop(){
if(size = = 0)
throw new EmptyStackException();
Object result = elements[--size];
//加上这一句
elements.[size]=null;
return result;
}

六,避免使用终结(finalizer)函数
原因：终结函数通常是不可预测的，一般情况下不要使用，使用的结果会带来很多问题，不稳定，性能差，移植问题等等。
分析原因：
1,从一个对象不可到达到它的终结函数被执行，这段时间是任意的，不确定的，所以时间关键的系统不应该使用终结函数。
2,及时的执行终结函数是垃圾回收算法决定的，这种算法在不同的JVM实现中会大相径庭，使用终结函数的结果就是导致移植性问题
3,如果执行终结函数的线程一直低于当前的线程的优先级，很可能造成占用大量内存，极端情况是出现OutOfMemoryError
4,JSL不保证终结函数一定被执行，所以不要依赖终结函数来更新关键性的永久状态，例如数据库的永久锁
5,
不要相信System.gc()
System.runFinalization这两个函数，它们只能提高终结函数的执行机会，并不保证一定执行。唯一保证一定执行的是
System.runFinalizersOnExit喝Runtime.runFinalizersONExit()但这两个方法已经被声明不建议使
用.
6,一个在终结函数中的一场不会打出任何信息
七:在改写equals方法的时候遵守通用约定
分析：
1,有些情况下不要随意改写equals
(1),一个类的每个实例本质上是唯一的，例如Thread
(2),不管新一个类是否提供了“逻辑相等”的测试功能，例如java.util.Random
(3),超类已经改写了equals，从超类继承过来的行为对于子类也是适合的 例如Set从AbstractSet继承了equals
(4)，一个类是私有的，或者是包级私有的，并且确定它的equals方法永远不会被调用
2, 通用的约定
自反性: 对于任意的引用值x ,x.equals(x)一定为true
对称性: 对于任意的引用值x,y x.equals(y)返回true是 y.equals(x)也一定返回true
传递性：对于任意的引用值x,y,z 如果x.equals(y)返回true 并且y.equals(z)返回true 那么 x.equals(z)也一定是true
一致性：对于任意的x,y如果x,y没有被更改，调用任意多次x.equals(y)返回的结果应该一样。
非空性：对任意的引用x ,x.equals(null)一定返回false
3不要将equals声明中的Object对象换成别的类型
4，不要让equals方法依赖不可靠资源


八：改写equals方法时总要改写hashCode
原因：来自java.lang.Object关于hashCode的规范
1,在一个应用执行期间，如果一个对象的equals方法比较所用到的信息没有修改的话，那么对该对象调用hashCode多次，比如如一的返回同一个数
2,如果两个对象的equals方法返回true，那么分别调用hashCode方法返回的值应该相等
3,在两个兑现的equals方法返回false时，尽可能的让hashCode方法返回的值不相等，提高散列表的性能
分析：如果改写了equals没有改写hashCode在使用map等集合类的时候会出现问题。
九：尽可能的改写toString方法，并在显示内容中尽可能的包括令人感兴趣的信息。并且在注释中表示出你的意图。
十：谨慎的改写clone方法，改写前考虑浅拷贝和全拷贝
十一：考虑实现Comparable接口，如果你的对象要排序，那么记得实现这个方法
十二：使类和成员的可访问能力最小化,
十三：支持非可变性
非可变性遵循以下的原则：
1,不提供任何改变对象的方法
2,保证没有可被子类改写的方法
3,保证所有的域都使final
4,使所有的域都成为私有的
5,保证任何可变组件互斥访问
6，非可变对象本质是线程安全的，不需要同步

十四：复合优于继承（Think in java中有不少说明)
十五：要们专门为继承而设计，并给出文档说明，要么禁止继承
十六：接口优于抽象类(参考一下GOF的设计模式)
十七：接口只是被定义类型，不要试图使用常量接口
十八：优先考虑静态成员类
说明：嵌套类有四种
静态成员类 ， 非静态成员类， 匿名类， 局部类 除了第一种之外，其它三种都被称为内部类
1,静态成员类是一种最简单的嵌套类，最好把它看成一个普通类，只是碰巧被声明在另一个类内部而已，
它
可以访问外围类的所有成员，包括那些生民为私有的成员。静态成员类是外围类的一个静态成员，也遵守同样的可访问性规则，如果它被声明为私有的，那么它只能
在外围类内部可以访问。静态成员类的一个用法是公有的辅助类。例如HashMap的 static class Entry

非静态成员类和静态成员类的区别主要是非静态成员类需要一个外围类实例的引用，如果你不需要访问外围类的实例的话，记得使用静态成员类。

匿名类被使用的相对多一些，但是大量的使用匿名类会让你的代码比较乱，作过GUI开发的人多会有所感触。并且记住，尽可能的让你的匿名类短小。

局部类，局部类的使用是最少的，很少会使用到这个，如果用到记得使局部类尽可能的短小

对于C语言用户的部分
十九：用类代替结构
二十：用类层次代替联合
二十一：用类来代替enum，但是在jdk1.5的时候提供了enum的支持，有些东西不一样了
二十二：用类和接口代替函数指针


三十一、如果要求精确的答案，尽量避免使用float 和double，这个可以参照我的一片文章
货币尤其不合适。可以使用BigDecimal代替
三十二、如果其它类型更适合，尽量避免使用字符串
1,字符串不能替代其它的值类型
2,字符串不适合代替枚举类型
3,字符串不适合代替聚集类型
4,字符串也不是和代替能力表
因为有些时候，使用字符串会大大降低性能
三十三、了解字符串连接的性能
说明：使用StringBuffer代替 +来连接字符串
三十四、通过接口来引用对象，这能让你的程序更加灵活
三十五、接口优先于反射。
使用反射会带来很多问题，例如：
1,不能编译期发现错误
2,代码混乱
3,调试困难
4,性能损失。
除非必须，否则不使用反射
三十六、谨慎的使用本地方法JNI
三十七、谨慎的进行优化，有三条优化格言：
1,很多计算上的过失都被归咎于效率原因（没有获得必要的效率），而不是其它的原因--甚至包括盲目的作傻事. ---William A.Wulf [Wulf72]
2,不要去计较一些小的效率上的得失，在97%的情况下，不成熟的优化是一切问题的根源。
------Donald E.Knuth[Knuth74]
3,在优化方面要遵守两个原则:
规则一：不要做优化
规则二：还是不要做优化--也就是说，在你还没有绝对清晰的未优化方案前，请不要优化。
-----M.A.Jackson[Jackson75]
每次试图做优化之前和之后请对性能进行测试
三十八：遵守普遍接受的命名规则
三十九：值针对不正常的条件才使用异常，也就是说不要在正常的情况下使用异常来控制流程，活着解决某些已知的问题。因为会大量的损失性能
四十、对于可恢复的条件使用被检查的异常，对于程序错误使用运行时异常
详细：Java提供了三种可抛出结构，checked Exception, run-time exception , error
什么时候使用什么很容易让人混淆，下边是一个简单的区分原则
1,如果期望调用者能够恢复，那么对于这样的条件应该使用被检查异常
2,你所实现的所有未检查的抛出结构都是run time exception ，而不是Error
四十一：避免不必要的使用被检查异常
四十二：尽可能的使用标准异常，例如IllegalArgumentException ,NullPointerException ,IndexOutOfBoundsException等等
四十三：抛出异常要适合于相应的抽象。
高层实现应该捕获异常，同时抛出一个可以按照高层抽象解释的异常（业务逻辑上符合高层逻辑），这种做法叫做异常转译
四十四：每个方法抛出的异常都应改有文档
四十五：在细节消息中包含失败－捕获信息
详细：在异常字符串中应包含有用的信息，例如IndexOutOfBoundsException异常的细节消息应该包括下界、上界以及没有落在其中的实际下标

四十六、努力使失败保持原子性
1,一般而言，一个失败的方法调用应该使对象保持"它在被调用之前的状态",具有这种属性的方法被称为具有
失败原子性。
四十七、不要忽略异常
例如这样的代码是错误的
try{
//.....
}catch(SomeException e){
}
四十八、对共享可变数据要同步访问
注：Java的双重检查模式并不保证一定正确
四十九、避免过多的同步
1,为了避免死锁的危险，在一个被同步的方法或者代码中，永远不要放弃对客户的控制。
2,通常同步区域内应该做尽可能少的工作
五十、永远不要在循环外部调用wait
五十一、不要依赖于线程调度器，因为这可能造成不可移植性
1,不要使用Thread.yield来修正程序，因为在不同的Jdk中，不能移植
2,线程优先级是Java平台上最不可移植的特征了。
3,对大多数程序员来说，Thread.yield的唯一用途是在测试期间人为的增加一个程序的并发行。
五十二、线程安全性的文档
一个类为了被多个线程安全的使用，必须在文档中姓储的说明它所支持的线程安全级别。
1,非可变。
2,线程安全的。
3,有条件的线程安全
4,线程兼容的
5,线程对立的。
五十三、避免使用线程组
五十四、谨慎的实现Serializable
五十五、考虑使用自定义的序列化形式
五十六、保护的编写readObject方法
五十七、必要时提供一个readResolve方法

http://blog.so8848.com/tag/effective-java