Effective Java

构造函数只能通过参数来区分，静态方法更易读

避免重复新建对象

能为重复的调用返回相同的对象，可以对实例严格控制

这种做法使得API可以返回对象又不会使得对象的类公有化。

同时暴露出来的是接口声明，用户不需要关心得到的对象的类，只需要关心这个是声明接口的子类（实现类）即可。

这主要是为了提升软件的可维护性和性能，因为返回的对象也会随着软件版本的变更而不同。这种模式也是服务提供者框架（Service Provider Framework）的基础。

Map<String,List<String>> m= new HashMap<String, List<String>>();

当你想要创建实例时，就利用参数列表最短的构造器。虽然重叠构造器模式可行，但是当有许多参数的时候，客户端代码会行难编写，并且难以阅读，随着参数的增加，它很快就失去控制。

创建实例容易，产生的代码读起来也容易

构造过程被分到几个调用中，在构造过程中JavaBean可能不一致

JavaBean不能做成不可变类，需要更加保证它的线程安全

像重叠构造器的安全性，也有JavaBean的易读性

不直接生成想要的对象，让客户端用需要的参数调用构造器（或静态工厂），得到一个builder对象

比重叠构造器更加冗长，适合多个参数使用

第一种是类自己管理内存，程序员就应该警惕内存泄露问题；一旦元素被释放掉，则该元素中包含的任何对象引用都应该被清空。

第二种是来源于缓存；

第三种是来源于监听器和其他回调。常见的解决办法是使用弱应用（weak reference），例如，只将它们保存成WeakHashMap中的键。

类的每个实例本质上都是唯一的

不关心类是否提供了逻辑相等（logical equality）的测试功能

超类已经覆盖了equals，从超类继承过来的行为对子类也是合适的

类是私有的或包私有的，可以确定它的equals方法永远不会被调用

对象有逻辑相等的概念（不等同于对象等同）

超类没有覆盖equals

值类（Value vlass）   Integer、Date

例外：值类，实例受控，每个值至多只存在一个对象。枚举类型。  对于这种类型，逻辑相同和对象等同是一回事

自反性。对任何非null的引用值x，x.equals(x)返回true

对称性。非null的x、y。当且仅当x.equals(y)为true时，y.equals(x)为true

传递性。非null的x、y、z。x.equals(y)返回true，y.equals(z)返回true，则x.equals(z)返回true

一致性。对于任何非null的引用值x和y，只要equals的比较操作在对象中所用的信息没有被修改，多次调用x.equals(y)就会一致地返回true，或者一致的返回false。

非null的x，x.equals(null)返回false

1.使用==操作符检查“参数是否为这么对象的引用”

2.使用instantOf检查“参数是否为正确的类型”

3.把参数转换为正确的类型

4.对于该类中的每个“关键”域，检查参数中的域是否与该对象中的对应域想匹配

5.当你编写完成equals方法后，应该问三个问题，是否是对称的、传递的、一致的

覆盖equals时总要覆盖hashCode

不要企图让equals过于智能

不要将equals声明中的Object对象替换为其它类型

1、  把某个非零的常数值，比如说17（值17是任选的，因为即使2.a步骤中计算出的散列值为0初始域也会影响到散列值，这样会大大的避免了冲突的可能性，所以这个一般是一个非零的常数值），保存在一个名为result的int的类型变量中。

2、  对于对象中每个键域f（指equals方法中涉及的每个域），完成以下步骤：

    a.  为该域计算int类型的散列码c：

        I、  如果该域是boolean类型，则计算(f ? 1 : 0)。

        II、 如果该域是byte、char、short或者int类型，则计算(int)f。

        III、如果该域是long类型，则计算(int)(f ^ (f >>> 32))。

        IV、 如果该域是float类型，则计算Float.floatToIntBits(f)，即将内存中的浮点数二进制位看作是整型的二进制，并将返回整型结果。

        V、  如果该域是dobule类型，则计算Double.doubleToLongBits(f)，然后按照步骤2.a.III。

        VI、 如果该域是一个对象引用，并且该类的equals方法通过递归地调用equals方式来比较这个域，则同样为这个域递归地调用hashCode。如果这个域的值为null，则返回0。

        VII、如果该域是一个数组，则要把每一个元素当做单独的域来处理。也就是说，递归地应用上述规则，对每个重要的元素计算一个散列码，然后根据步骤2.b中的做法把这些散列值组合起来。如果数组的每个元素都需要求，则可以使用1.5版本发行的Arrays.hashCode方法。

    b.  按照下面的公式，把步骤2.a中计算得到的散列码c合并到result中：

          result = 31 * result + c;

        步骤2.b中的乘法部分使得散列值依赖于域的顺序，如果一个类包含多个包含多个相似的域，这样的乘法运算就会产生一个更好的散列函数。例如，如果String散列函数省略了这个乘法部分，那么只要组成该字符串的字符是一样的，而不管它们的排列的顺序，则会导致只要有相同字符内容的字符串就会相等的问题，而String的equals方法是与字符排序顺序有关的。另外，之所以选择31，是因为它是一个奇素数。如果乘数是偶数，并且乘法溢出的话，信息就会全丢失，因为与2相乘等价于移位运算。31还有个很好的特性，即用移位和减法来代替乘法，可以得到更好的性能：31 * i = i ^32 - i =  (i << 5) – i，现代的VM可以自动完成这种优化。

3、  返回result。

4、  写完了hashCode方法后，问问自己“相等的实例是否都具有相等的散列码”。

指定格式，对于值类（电话号码），易于阅读

但是如果此格式大量应用，就要一直保持这种格式，缺乏灵活性

私有的东西将不被智能提示和导出到API文档中，这是内部的实现，而不是给外部暴露用，为了不使用户(使用这个类的人)疑惑和增加类的可变性，类暴露的接口，不是private修饰的都是可以被使用的，那么如果别人使用了你不该使用的部分，而你这个类下个版本更新，却删除了这个方法，将不止导致用户对于你的类的厌恶，而且会破坏原有的代码，所以就尽量私有化。
类的可访问性，缩小到最小，除非有必须暴露这部分的理由，否则就该是private，Effective c++中也提到过。

如果公有，就放弃了对存储在此域中的值进行限制的能力，放弃了域不可变的能力

包含公有可变类的域不是线程安全的

下面是摘自java.util.AbstractCollection的规范：

 

public boolean remove(Object  o)：

从此 collection 中移除指定元素的单个实例（如果存在）（可选操作）。更正式地说，如果该 collection 包含一个或多个满足 (o==null ? e==null : o.equals(e)) 的元素 e，则移除 e。如果该 collection 包含指定的元素（或等价元素，如果该 collection 随调用的结果发生变化），则返回 true。

此实现在该 collection 上进行迭代，查找指定的元素。如果找到该元素，那么它会使用迭代器的 remove 方法从该 collection 中移除该元素。注意，如果此 collection 的 iterator 方法所返回的迭代器无法实现 remove 方法，并且此 collection 包含指定的对象，那么此实现会抛出 UnsupportedOperationException。

该文档清楚地说明了，覆盖iterator方法将会影响remove方法的行为。而且，它确切地描述了iterator方法返回的Iterator的行为将会臬影响remove方法的行为。与此相反，在第16条的情形中，程序员在子类化HashSet时，并没有说明覆盖add方法是否会影响addAll方法的行为。

无法更新现有的类来扩展抽象类，如果要扩展，就要将抽象类放到类层次的高处

需要增加此功能的类只要implement一个interface即可

静态成员

非静态成员

匿名类

局部类

List逃避了泛型检查，List<Object>明确告诉编译器，它可以持有任意对象。

可以将List<String>传递给List，但是List<String>不能传递给List<Object>。因为泛型的子类化规则，List<String>是List的子类型，而List<String>不是List<Object>的子类型。

使用List就失掉了类型安全性，而使用List<Object>则不会。

Set<Lark> exalation = new HashSet<Lark>();

消除所有警告，可以确保代码是类型安全的，不会出现ClassCastException

在尽可能小的范围使用，不要在整个类上使用@SuppressWarinings

如果Sub是Super的子类型，那么数组Sub[]就是Super[]的子类型

任意两个不同类型Type1和Type2，List<Type1>既不是List<Type2>的子类型，也不是List<Type2>的超类型

在运行时才知道并检查它们的类型约束

只在编译时强化它们的类型，并在运行时擦除它们的元素类型信息

//The int enum pattern. Severely deficient
public static final int APPLE_FUJI     = 0;
public static final int APPLE_PIPPIN = 1;

public static final int ORANGE_NAVEL = 0;
public static final int APPLE_TEMPLE    = 1;

String枚举模式

public enum Apple {FUJI, PIPPIN}
public enum Apple {NAVEL, TEMPLE}

Java枚举本质上是int值

一个枚举如果是普适性的，那么就应该是顶层类；如果只是用在某个特定的顶层类中，它就应该是该顶层类的成员类

可以为枚举添加数据与方法

编写多个只接受有这种标记的方法

对于公有方法，@throw标签描述违反参数限制会抛出的异常

未导出的方法（unexported method），assertion，通过assert xxxx

有些参数，方法本身没用到，却被保存起来以后使用，如构造器。检查参数有效性尤为重要

在方法执行它的计算任务之前，应检查它的参数

在设计时，尽可能使参数通用，并符合实际要求。

方法对于它能接受的参数值都能完成合理的工作，对参数的限制应该越少越好

易于理解，风格一致

大众认可的名称

每个方法都应该尽其所能，方法太多使类难以学习、使用、文档化、测试和维护

对于类和接口所支持的每个动作，都提供一个功能齐全的方法

只有当一个动作被经常用到的时候，才考虑为它提供快捷方式。如不确定，还是不提供为好。

四个参数或者更少

使用Builder模式

为了编写代码的可维护性，还应为未被导出的类、接口...编写文档注释

如果类是可序列化的，应为类的可系列化形式编写文档

这个方法做了什么，而不是它如何完成这项工作的

为了使客户端能够调用，要满足什么条件。

调用成功完成之后，哪些条件必须要满足

系统状态中可以观察到的变化，如，方法启动了后台线程

@param、@return后应为名词短语，描述这个参数或者返回值所表示的值

@throws 开头应为 if，描述这个异常在什么情况下会被抛出

循环终止后不再需要循环变量，for优于while

过滤

转换

平行迭代

java.lang、java.util、java.io，其他根据需要

jdk1.2 Collections Framework集合框架加入java.util

jdk1.5 java.util.concurrent加入了一组并发实用工具

尤其不适合用于货币计算

int、double、long...

    装箱基本类型
（boxed primitive）

...

jdk1.5 自动装箱、自动拆箱

数据进入到程序中，除非数据本身确实是文本信息，
否则转换成对应的int、float，
以及“是-或者-否”转换成boolean
如果存在适当的值类型，不管是基本类型还是对象引用，大多应该使用这种类型
如果不存在这样的类型，就应该编写一个类型

反射允许一个类使用另一个类，即使当前者被编译的时候后者还不存在

丧失了编译时类型检查的好处，
包括异常检查，如果程序调用了不存在或者不可访问的方法，在运行时它将会失败，除非做了特别的预防措施。

执行反射访问所需要的代码非常笨拙和冗长

性能损失

很多计算上的过失都被归咎于效率（没有必要达到的效率），而不是任何其他的原因——甚至包括盲目的做傻事。                                                                                                                                                ——William A. Wulf[Wulf72]

不要去计较效率上的一些小小的损失，在97%的情况下，不成熟的优化才是问题的根源。    
                                                                                                                                   ——Donald E. Knuth[Knuth74]

在优化方面，我们应该遵守两条规则：
规则1：不要进行优化。
规则2（仅针对专家）：还是不要进行优化——也就是说，在你还没有绝对清晰的优化方案之前，请不要进行优化。                                                                                                                                              ——M.A.Jackson[Jackson75]

Executor Framework

并发集合（Concurrent Collection）

同步器（Synchronizer）

（immutable）不可变的

（unconditionally thread-safe）无条件的线程安全

（conditionally thread-safe）有条件的线程安全

（not thread-safe）非线程安全

（thread-hostile）线程对立的

虽然延迟初始化主要是一种优化，但它也可以用来打破类和实例初始化中的有害循环。

就像大多数优化一样，对于延迟初始化，最好建议“除非绝对必要，否则就不要这么做”（见第55条）。

它降低了初始化类或者创建实例的开销，却增加了访问被延迟初始化的域的开销。

测量类在用和不用延迟初始化时的性能差别。选择进步进行延迟初始化。

当有多个线程时，延迟初始化是有技巧的。
如果两个或多个线程共享一个延迟初始化的域，采用某种形式的同步是很重要的，否则就可能造成严重的Bug（见第66条）。

对于可以接受重复初始化的实力域，可以考虑使用单重检查（single-check idiom）

接受了默认序列化的形式，这个类中的私有的和包级私有的实力域将都变成导出API的一部分。
这不符合“最低限度地访问域”（见第13条）的实践标准。

反序列化机制（deserialization）是一个“隐藏构造器”，因为反序列化机制中没有显示构造器，很容易忘了确保“反序列化过程必须也要保证由真正构造器建立起来地约束关系”。

使用默认的反序列化机制，很容易使对象的约束关系遭到破坏，以及遭受到非法访问（见第76条）。

内部类的默认序列化形式是定义不清楚的