共计 11527 个字符，预计需要花费 29 分钟才能阅读完成。
《Effective Java》Java 名著，必读。如果能严格听从本文的准则，以编写 API 的品质来奢求本人的代码，会大大晋升编码素质。
以下内容只记录了我本人整顿的货色，还是倡议读原文。为了聚焦知识点，一些阐明成心疏忽掉了。相当于是一篇摘要。
1、思考用动态工厂办法代替构造函数
例子：
Integer.valueOf(“1”)、Boolean.valueOf(“true”)等。
劣势：
- 可读性高（办法名）
- 性能（不肯定创建对象）
- 灵活性高
上面针对三个劣势进行一些解读。
可读性高
new Point(x,y) 和 Point.at(x,y)、Point.origin()。构造函数只能看出两个参数，不知其意，后者更易了解。
性能
在某些状况下，能够当时进行实例化一些对象，调用时间接调用即可，不须要进行扭转。比方，Boolean。
public final class Boolean implements Serializable, Comparable<Boolean> {
// 事后设置两个对象
public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);
public Boolean(boolean var1) {this.value = var1;}
public Boolean(String var1) {this(parseBoolean(var1));
}
// 工厂办法
public static Boolean valueOf(boolean var0) {return var0?TRUE:FALSE; // 返回事后设置的对象，而不是创建对象}
// 工厂办法
public static Boolean valueOf(String var0) {return parseBoolean(var0)?TRUE:FALSE;
}
// ... other code
} 灵活性高
可依据具体情况，返回子类。相当于更弱小的工厂。间接从父类获取到子类。尤其实用于工具类（提供各种 API）。例子：Collections。
public class Collections {
// 公有，典型工厂
private Collections() {}
public static final List EMPTY_LIST = new EmptyList<>();
// 工厂办法
public static final <T> List<T> emptyList() {return (List<T>) EMPTY_LIST;
}
private static class EmptyList<E> extends AbstractList<E> implements RandomAccess, Serializable {// code}
// 工厂办法
public static <E> List<E> checkedList(List<E> list, Class<E> type) {
// 依据具体情况，获取相应子类
return (list instanceof RandomAccess ?
new CheckedRandomAccessList<>(list, type) :
new CheckedList<>(list, type));
}
// 子类 1
static class CheckedRandomAccessList<E> extends CheckedList<E> implements RandomAccess {CheckedRandomAccessList(List<E> list, Class<E> type) {super(list, type);
}
public List<E> subList(int fromIndex, int toIndex) {
return new CheckedRandomAccessList<>(list.subList(fromIndex, toIndex), type);
}
}
// 子类 2
static class CheckedList<E> extends CheckedCollection<E> implements List<E> {// code}
} 2、多个构造函数时，思考应用结构器
尤其在进行 Android 开发时，会碰到这种状况。通常是一个对象，具备多个成员变量可能须要初始化，惯例办法，须要提供大量构造函数。例如：
// 非 Android 中的 AlertDialog，便于阐明问题，举个例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
private AlertDialog(){}
public AlertDialog(int width, int height){ // 空白的正告框
AlertDialog(width,height,null);
}
// 带题目的正告框
public AlertDialog(int width, int height, String title){ // 带题目的正告框
AlertDialog(width, height, title, "确定");
}
// 带题目的正告框，有确定按钮
public AlertDialog(int width, int height, String title, String confirm){AlertDialog(width, height, title, confirm, null);
}
// 带题目的正告框，有确定按钮，勾销按钮
public AlertDialog(int width, int height, String title, String confirm, String denyText){// set every thing.}
} 有多种款式的正告框，为了调用不便，必须提供多个构造函数。否则用户在调用时，只能应用残缺构造函数，容易犯错且无奈进行浏览。极不灵便。如果采纳另外一种形式，则能够解决，但会破费很多经验解决并发的状况:
// 非 Android 中的 AlertDialog，便于阐明问题，举个例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
public AlertDialog(){}// 空白的构造函数
public void setWidth(int width){this.width = width;}
// 其余 set 办法
} 调用时，通过调用各个参数的 set 办法进行设置。问题来了：
- 并发
- 无奈进行参数校验。
例如，只创立了对象，设置了题目，却没有尺寸，相当于创立了一个没有尺寸的正告框。
在 Android 中，大量的控件都应用了结构器 Builder。
// 非 Android 中的 AlertDialog，便于阐明问题，举个例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
// private
private AlertDialog(){}
// Builder 中应用
protected AlertDialog(Builder b){
width = b.width;
height = b.height;
// .....
if(width==0||height==0) throws new Exception("size must be set");
}
// 结构器
public static class Builder {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
// 留神：返回的 Builder。public Builder setTitle(String title) {
this.title = title;
return this;
}
// 其余 set...
public AlertDialog build(){return AlertDialog(this);
}
}
} 于是，能够依据相应需要，进行相应设置，并在 AlertDialog 真正结构时，进行参数校验。就像这样：
new AlertDialog.Builder().setTitle("提醒").build(); 上述例子，会胜利抛出异样。
3、用私有化结构器或者枚举型强化 Singleton。
Singleton 指最多会被实例化一次的类。通常状况下，以前的做法是没有问题的。然而在某些高级状况，通过应用反射的相干常识拜访 private 的构造函数，毁坏 Singleton。
public class Elvis{
// 留神，私有 final 对象
public static final Elvis INSTANCE = new Elvis();
private Elvis(){}
} 另一种状况，在序列化的过程中，反序列化失去的对象曾经不再是以前的对象（毁坏了 Singleton），这种状况下，能够通过单元素枚举型解决。
public enum Elvis{
INSTANCE;
// some methods
} 4、通过私有化结构器强化不可实例化的能力
有一些工具类，仅仅是提供一些能力，本人自身不具备任何属性，所以，不适宜提供构造函数。然而，缺失构造函数编译器会主动增加上一个无参的结构器。所以，须要提供一个私有化的构造函数。为了避免在类外部误用，再加上一个保护措施和正文。
public class Util{private Util(){
// 抛出异样，避免外部误调用
throw new AssertionError();}
} 弊病是无奈对该类进行继承（子类会调用 super()）。
5、防止创立不必要的对象
- 对象的重用
- 低廉的对象，应用对象池
- 便宜的对象，慎用对象池。
古代 JVM 对便宜对象的创立和销毁十分快，此时不适于应用对象池。
6、打消过期的对象援用
以下三种状况可能会造成内存泄露：
- 本人治理的内存（数组长度减小后，pop 出的对象容易导致内存透露）
缓存 - 监听和回调
- 本人治理的内存
对于本人治理的内存要小心，比方：
public class Stack{private Object[] elements;
private int size = 0;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
public Stack(){elements = new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e){ensureCapacity();
elements[size++]=e; // allocate 新的堆内存和栈内存
}
public Object pop(){if(size==0) throw new EmptyStackException();
return element[--size]; // pop 出 element[size]，该对象不再无效。内存透露起因。}
private void ensureCapacity(){if(elements.length==size)
elements = Arrays.copyOf(elements, 2*size+1);
}
} 弹出的对象不再无效，但 JVM 不晓得，所以会始终放弃该对象，造成内存泄露。
解决：
public Object pop(){if(size==0) throw new EmptyStackException();
elements[size] = null; // 期待回收
return element[--size];
} 缓存
缓存的对象容易被程序员忘记，须要设置机制来保护缓存，例如不定期回收不再应用的缓存（应用定时器）。某些状况下，应用 WeakHashMap 能够达到缓存回收的效用。注，只有缓存依赖于外部环境，而不是依赖于值时，WeakHashMap 才无效。
监听或回调
应用监听和回调要记住勾销注册。确保回收的最好的实现是应用弱援用（weak reference），例如，只将他们保留成 WeakHashMap 的键。
7、防止显示调用 GC
Java 的 GC 有弱小的回收机制，能够简略的记住：不要显示调用 finalizer。能够这样了解：
jvm 是针对具体的硬件设计的，然而程序却不是针对具体硬件设计的，所以，java 代码无奈很好的解决 gc 问题（因为他具备平台差异化）。另外，finalizer 的性能开销也十分大，从这个角度上思考也不应该应用它。
8、笼罩 equals 办法请恪守通用约定
- 自反性。x.equals(x) == true
- 对称性。以后仅当 y.equals(x)==true 时，x.equals(y)==true
- 传递性。if(x.equals(y)&&y.equals(z))，y.equals(z)==true
一致性。 - 非空性。x.equals(null)==false
9、笼罩 equals 办法时总要笼罩 hashCode
为了保障基于散列的汇合应用该类（HashMap、HashSet、HashTable），同时，也是 Object.hashCode 的通用约定，笼罩 equals 办法时，必须笼罩 hashCode。
10、始终笼罩 toString
Object 的 toString 办法的通用约定是该对象的形容。留神笼罩时，如果有格局，请备注或者严格依照格局返回。
11、审慎笼罩 clone
12、思考实现 Comparable 接口
13、使类和成员的可拜访性最小化
目标是解耦。简略来讲，应用修饰符的优先级从大到小，private>protected>default(缺省)>public。如果在设计之初，设计为 private 修饰符后，在之后的编码过程如果不得不扩充其作用于，应该先查看是否设计的确如此。
子类笼罩超类，不容许拜访级别低于超类的拜访级别。（超类的 protected，子类笼罩后不能改为 default）。
成员变量决不允许是私有的。一旦设置为私有，则放弃了对他解决的能力。这品种并不是线程平安的。即便是 final 的，也不容许。除非心愿通过 public static final 来裸露常量。成员变量总是须要应用 setter 和 getter 来保护。有一个例外：长度非零的数组。这是安全漏洞的一个本源。
public Object pop(){if(size==0) throw new EmptyStackException();
elements[size] = null; // 期待回收
return element[--size];
} 改良：
private static final Thing[] PRIVATE_VALUES = {...}
// 此时获取到的才是“常量”public static final List<Thing> VALUS =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES)) 另一种：
private static final Thing[] PRIVATE_VALUES = {...}
// 此时获取到的才是“常量”public static final Thing[] values(){return PRIVATE_VALUES.clone();
} 14、在私有类中应用拜访办法而非公有成员变量（相似 13）
15、使可变性最小化
16、复合优先于继承
继承有利于代码复用，然而尽可能不要进行跨包的继承。包内的继承是优良的设计形式，一个包里的文件处在同一个程序员的管制之下。然而继承有其局限性：子类依赖于超类。超类一旦产生更改，将可能毁坏子类。并且，如果超类是有缺点的，子类也会得“遗传病”。
复合，即不扩大已有的类，而是在的类中新增一个现有类的。相当于现有类作为一个组建存在于新类中。如此，将只会用到须要用到的货色，而不体现现有类所有的办法和成员变量。新类也能够称为“包装类”，也就是设计模式中的 Decorate 模式。
17、要么就为继承而设计，并提供文档阐明，要么就禁止继承
18、接口优于抽象类
19、接口只用于定义类型
20、类档次优先于标签类
21、用函数对象示意策略
函数参数能够传入相似 listener 的对象，目标是应用 listener 中的办法。如果应用匿名的参数，每一次调用会创立新的对象。能够将 listener 申明为成员变量，每次都复用同一个对象，并且能够应用动态域（static 变量）。比方 String 类的 CASE_INSENSITIVE_ORDER 域。
22、优先思考动态类成员
嵌套类的目标应该只是为了他的外围类提供服务，如果当前还可能用于其余环境中，则应该设计为顶层类。动态类相当于一个一般的外部类，只是恰好申明在了一个类外部。通常的用户是：Calculator.Operation.PLUS 等。和一般类的区别只是，在 PLUS 前，有了 2 个前缀，来表明其含意。而非动态类必须存在于外部类对象中。不要手动在内部创立一个外部非动态类对象，创立的过程是：instance.New MemberClass()。这十分奇怪。
如果成员类不须要拜访外围类，则须要增加 static，是他成为动态成员类，否则每个实例都将蕴含一个额定指向外围对象的援用。将会影响垃圾回收机制。
23、应指定泛型的具体类型，而不是间接应用原生类型。
例如，应该指定 List，而不倡议间接应用 List。
24、打消非首检正告
在应用 IDE 进行编码时，弱小的 IDE 都会在你编码过程中提醒 warning，须要尽可能的打消 warning，至多，应该小心这些 warning。慎用 SuppresWarning，如果 IDE 提醒你能够通过增加该注解解决掉 warning，请不要那么做。如果切实要应用，请增加正文阐明起因。
25、列表优先于数组
类比泛型，数组是有肯定缺点的。List 和 List 是没有关系的，而 Sub[]是 Super[]的子类。
// Fails at runtime
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in"; // throw exception
// won't compile
List<Object> ol = new ArrayList<Long>(); // Incompatible types
ol.add("I don't fit in"); 从代码中能够看到，应用泛型，会提前发现错误。
26、优先思考泛型
27、优先思考泛型办法
28、利用有限度通配符来晋升 API 的灵活性
PECS，producer-extends，consumer-super。
//public class Stack<E>{// public Stack();
// public void push(E e);
// public E pop();
// public boolean isEmpty();
//}
public void pushAll(Iterator<? extends E> src){for(E e : src)
push(e);
}
public void popAll(Collection<? super E> dst){while(!isEmpty()){dst.add(pop());
}
}
// Get and Put Principle 所有 comparable 和 comparator 都是消费者（Consumer）。
29、优先思考类型平安的异构容器
30、用 enum 代替 int 常量
public enum Apple {FUJI, PIPPIN, GRANNY_SMITH}
public enum Orange {NAVEL, TEMPLE, BLOOD} 枚举型在 java 中十分弱小，当须要一组固定常量时，应用 enum 比 int 好很多。比方代码可读性，安全性等。
31、enum 用实例域代替序数
// bad solution
public enum Ensemble {
SOLO, DUET, TRIO, QUARTET, QUINTET,
SEXTET, SEPTET, OCTET, NONET, DECTET;
public int numberOfMusicians() { return ordinal() + 1; }
}
//
// improvement
public enum Ensemble {SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),
SEXTET(6), SEPTET(7), OCTET(8), NONET(9), DECTET(10), TRIPLE_QUARTET(12);
private final int numberOfMusicians;
Ensemble(int size) {this.numberOfMusicians = size;}
public int numberOfMusicians() { return numberOfMusicians;}
} 永远不要像第一种的形式，利用序数拜访 enum，须要在构造函数中应用参数来初始化。
32、用 EnumSet 代替位域
public class Text{
public static final int STYLE_BOLD = 1 << 0; // 1
public static final int STYLE_ITALIC = 1 << 1; // 2
public static final int STYLE_UNDERLINE = 1 << 2; // 4
public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8
public void applyStyles(int styles){// ...}
}
//
text.applyStyles(STYLE_BOLD | STYLE_ITALIC); 以上叫做位图法，然而有更好的计划来传递多组常量——EnumSet。
public class Text{public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH}
// 留神此处，应用的是 Set 而不是 EnumSet
public void applyStyles(Set<Style> styles){// ...}
}
//
text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC)); 33、用 EnumMap 代替序数索引
任何时候都不要应用 enum 的 ordinal()办法。
34、用接口模仿可伸缩的枚举
35、注解优先于命名模式
36、保持应用 Override 注解
38、查看参数的有效性
私有办法查看参数，参数异样须要跑出 Exception。公有办法利用断言 assertion 查看参数。
39、必要时进行保护性拷贝
假如类的客户端会尽其所能来毁坏这个类的约束条件，因而你必须保护性的设计程序。以下是一个不可变类的设计。
public Period(Date start, Date end){this.start = new Date(start); // 应用了值的拷贝，没有应用原对象（指针）this.end = new Date(end);
if(this.start.compareTo(this.end)>0)
throw new IllegalArgumentException(start + "after" + end)
} 留神：保护性拷贝是在查看参数之前进行的，避免多线程的影响。不要应用 clone 办法进行保护性拷贝。
以上办法进攻了传入参数的批改，然而对于 get 办法获取到的对象，依然能够被批改，通过以下办法能够避免这种攻打。
public Date start(){return new Date(start);
}
public Date end(){return new Date(end);
} 40、审慎设计办法签名
41、慎用重载
42、慎用可变参数
43、返回 0 长度的数组或者汇合，而不是 null
null 个别用于示意没有被初始化或解决，如果办法返回了 null，则须要在下层做更多的解决，以避免 NPE。
44、为所有导出的 API 元素编写文档正文
正确的 javadoc 文档，须要每个被导出的类、接口、结构器、办法和域之前减少文档正文。正文应该是对实现通明的，只须要简洁的形容它和客户端之间的约定。并且，还应该附上该办法的副作用。
45、将局部变量的作用域最小化
46、for-each 优先于 for 循环
for-each 躲避掉了 for 循环的 index 变量的援用，通常来说它是不必要的——会减少引入谬误的危险，并且危险一旦产生，很难被发现。不过有三种状况下，无奈应用 for-each（注：在 jdk1.8 中曾经很好的解决了这些问题）。
- 过滤
- 转换
- 平行迭代
47、如果须要准确的答案，请防止应用 float 和 double
float 和 double 是执行的二进制浮点运算，目标是在宽泛数值范畴上应用准确的疾速近似计算而设计的。然而他们并没有提供齐全准确的计算（理论利用中，常常会碰到呈现 x.99999 等后果）。尤其是，在进行货币计算时，他们并不实用。比方：
System.out.println(1.03-.42); 失去的后果将是：0.610000000001。
为了解决这个问题，须要应用 BigDecimal。然而这也有一些问题，绝对于一般的运算，它显得更加麻烦，而且也更慢。通常来说后一个毛病能够疏忽，然而前者可能会让人很不难受。有一种做法是将须要解决的数值 *10(或更多），应用 int 进行计算，不过须要你本人解决四舍五入等操作。
48、根本类型优先于装箱根本类型
根本类型只有值，装箱类具备与他们值不同的同一性。
根本类型只有性能齐备的值，装箱类还具备非性能值：
null。
所以你可能会碰到 NPE
根本类型省空间省工夫
50、如果有更准确的类型，请防止应用字符串
字符串不适宜代替其余值的类型。
例如：int，boolean 等
- 不适宜代替枚举类型（第 30 条）
- 不适宜汇集类型
50、当心字符串连贯的性能
操作符“+”能够将多个字符串进行连贯。然而在大规模应用“+”的状况下，连贯 n 个字符串的开销是 n 的平房级工夫。这是因为字符串的不可变性导致的。在这种状况下请应用 StringBuilder 进行连贯。
51、通过接口援用对象
52、接口优先于反射机制
应用反射机制会带来以下的问题：
- 丢失了编译期类型查看
- 代码蠢笨简短
- 性能损失
反射基本上只适宜用在编写组件时、代码分析器、RPC 等场景下应用。在应用反射机制时，如果可能，尽可能只通过反射机制实例化对象，而拜访办法时，应用已知的接口或者超类。
53、审慎应用 JNI
54、审慎进行优化
很多计算上的差错都被归咎于效率（没有必要达到的效率），而不是任何其余起因——甚至包含自觉的做傻事。
——William A. Wulf
不要去计较效率上的一些小小的得失，在 97% 的状况下，不成熟的优化才是所有问题的本源。
——Donald E. Knuth
在优化方面，咱们应该恪守两条规定：
规定 1: 不要进行优化。
规定 2（仅针对专家）：还是不要进行优化——也就是说，在你还没有相对清晰的优化计划前，请不要进行优化。
——M. A. Jackson
这些格言比 java 的呈现还要早 20 年。他们讲述了一个对于优化的粗浅事实：优化的弊大于利。
要致力编写好的程序，而不是快的程序。低耦合的重要性远远大于性能。当程序编写得足够低耦合后，通过工具发现了性能瓶颈的代码块，才能够保障对其的批改不影响任何外部环境。
55、恪守广泛的命名规定
56、只针对异常情况才应用异样
不要尝试通过异样机制来做失常代码应该做的事件，比方，查看数组下标。
jvm 很少对异样进行优化，因为它只用于不失常的状况。并且，如果你将代码放入 try-catch 代码块，jvm 就丢失了原本能够对它进行的优化。
57、对于可复原的状况应用受检异样，对于编程谬误的状况应用运行时异样
如果冀望调用者适当的复原，则须要应用受检异样，强制调用者食用 try-catch 代码块，或者将他们抛出去
当调用产生前提违例——违反约定的状况时，应用运行时异样，这个时候程序曾经无奈再执行上来了。
例如调用数组的 - 1 索引。
作者：Dong GuoChao
欢送关注我的微信公众号「码农解围」，分享 Python、Java、大数据、机器学习、人工智能等技术，关注码农技术晋升•职场解围•思维跃迁，20 万 + 码农成长充电第一站，陪有幻想的你一起成长
