《Effective JavaJava》名著，必读。如果能严格听从本文的准则，以编写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办法进行设置。问题来了：

  1. 并发
  2. 无奈进行参数校验。例如，只创立了对象，设置了题目，却没有尺寸，相当于创立了一个没有尺寸的正告框。

在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 static final Thing[] VALUES = {...}

改良：

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<E>，而不倡议间接应用List。

24、打消非首检正告

在应用IDE进行编码时，弱小的IDE都会在你编码过程中提醒warning，须要尽可能的打消warning，至多，应该小心这些warning。慎用SuppresWarning，如果IDE提醒你能够通过增加该注解解决掉warning，请不要那么做。如果切实要应用，请增加正文阐明起因。

25、列表优先于数组

类比泛型，数组是有肯定缺点的。List<SuperClass>和List<SubClass>是没有关系的，而Sub[]是Super[]的子类。

// Fails at runtimeObject[] objectArray = new Long[1];objectArray[0] = "I don't fit in";       // throw exception // won't compileList<Object> ol = new ArrayList<Long>();   // Incompatible typesol.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 solutionpublic enum Ensemble {    SOLO, DUET, TRIO, QUARTET, QUINTET,     SEXTET, SEPTET, OCTET, NONET, DECTET;     public int numberOfMusicians() { return ordinal() + 1; }}//  // improvementpublic 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中曾经很好的解决了这些问题）。

  • 过滤
  • 转换
  • 平行迭代

48、如果须要准确的答案，请防止应用float和double

float和double是执行的二进制浮点运算，目标是在宽泛数值范畴上应用准确的疾速近似计算而设计的。然而他们并没有提供齐全准确的计算（理论利用中，常常会碰到呈现x.99999等后果）。尤其是，在进行货币计算时，他们并不实用。比方：

System.out.println(1.03-.42);

失去的后果将是：0.610000000001。

为了解决这个问题，须要应用BigDecimal。然而这也有一些问题，绝对于一般的运算，它显得更加麻烦，而且也更慢。通常来说后一个毛病能够疏忽，然而前者可能会让人很不难受。有一种做法是将须要解决的数值*10(或更多），应用int进行计算，不过须要你本人解决四舍五入等操作。

49、根本类型优先于装箱根本类型

  • 根本类型只有值，装箱类具备与他们值不同的同一性。
  • 根本类型只有性能齐备的值，装箱类还具备非性能值：null。所以你可能会碰到NPE
  • 根本类型省空间省工夫

50、如果有更准确的类型，请防止应用字符串

  • 字符串不适宜代替其余值的类型。例如：int，boolean等
  • 不适宜代替枚举类型（第30条）
  • 不适宜汇集类型

51、当心字符串连贯的性能

操作符“+”能够将多个字符串进行连贯。然而在大规模应用“+”的状况下，连贯n个字符串的开销是n的平房级工夫。这是因为字符串的不可变性导致的。在这种状况下请应用StringBuilder进行连贯。

52、通过接口援用对象

53、接口优先于反射机制

应用反射机制会带来以下的问题：

  • 丢失了编译期类型查看
  • 代码蠢笨简短
  • 性能损失

反射基本上只适宜用在编写组件时、代码分析器、RPC等场景下应用。在应用反射机制时，如果可能，尽可能只通过反射机制实例化对象，而拜访办法时，应用已知的接口或者超类。

54、审慎应用JNI

55、审慎进行优化

很多计算上的差错都被归咎于效率（没有必要达到的效率），而不是任何其余起因——甚至包含自觉的做傻事。

——William A. Wulf

不要去计较效率上的一些小小的得失，在97%的状况下，不成熟的优化才是所有问题的本源。

——Donald E. Knuth

在优化方面，咱们应该恪守两条规定：

规定1:不要进行优化。

规定2（仅针对专家）：还是不要进行优化——也就是说，在你还没有相对清晰的优化计划前，请不要进行优化。

——M. A. Jackson

这些格言比java的呈现还要早20年。他们讲述了一个对于优化的粗浅事实：优化的弊大于利。

要致力编写好的程序，而不是快的程序。低耦合的重要性远远大于性能。当程序编写得足够低耦合后，通过工具发现了性能瓶颈的代码块，才能够保障对其的批改不影响任何外部环境。

56、恪守广泛的命名规定

57、只针对异常情况才应用异样

不要尝试通过异样机制来做失常代码应该做的事件，比方，查看数组下标。

jvm很少对异样进行优化，因为它只用于不失常的状况。并且，如果你将代码放入try-catch代码块，jvm就丢失了原本能够对它进行的优化。

58、对于可复原的状况应用受检异样，对于编程谬误的状况应用运行时异样

  • 如果冀望调用者适当的复原，则须要应用受检异样，强制调用者食用try-catch代码块，或者将他们抛出去
  • 当调用产生前提违例——违反约定的状况时，应用运行时异样，这个时候程序曾经无奈再执行上来了。例如调用数组的-1索引。

58、防止不必要的受检异样

残缺的Java高级，高级对应的学习路线和材料！专一于java开发。分享java根底、原理性知识、JavaWeb实战、spring全家桶、设计模式、分布式及面试材料、开源我的项目，助力开发者成长！能够退出我的十年Java学习园地。