Effective Java阅读心得

最近再次拜读了Effective Java一书，确实很有感悟，第一次读的时候我的java基础还很不牢，代码积累也不多，读起来总是云里雾里，而这一次读的时候，确实有很多共鸣，感悟，在书上自己写了一些心得体会，俗话说好记性不如烂笔头，也记录到博客里，有需要的时候可以查阅一下

第一章  引言

引言部分就没啥说的了，就是介绍一下本书

第二章  创建和销毁对象

第一条：考虑用静态工厂方法代替构造器

其实这里指的静态工厂方法，通俗易懂的来说就是通过一些自定义的静态方法，return new一个该类或者该类的子类的实体，相比于普通的构造方法，优势有：

1，因为构造方法必须和类名保持一致，所以自定义的静态方法的命名更有指向性，而不是需要看参数及注释才看得懂这个构造方法用于构造什么样的对象

2，可以用静态方法返回相同对象，保持唯一性，并且节约资源

3，可以返回其子类的实体

4，很多情况下代码会更加简洁易懂

当然，并不是说所有构造方法都应该用静态方法来代替，它的使用场景通常是用于需要构造不同属性的同一个类的对象，或者是为了保持唯一性

第二条：遇到多个构造器参数时要考虑用构建器

在新建一个具有很多属性的对象的情况下，我们需要考虑到是否有一些特殊情况，比方说这个对象的属性很多，并且其中有很多可选属性，这种情况下用普通的方式肯定效率很低且极易出错，举个例子，假设有3个属性，可以两两任选，那就至少得写3个方法，4个就得6个，假设有几十个属性，这个实体类算是没法维护了。。。。。。

这种情况下有两种解决方法，一种是用的比较广的JavaBean，即用一个无参方法构建对象，然后用set方法去写参数，这样无论有多少个参数，写好对应的set方法就够了

但是文中提到它的缺点，即每传入一个参数，调用一次set方法，以为它没有顺序性可言，所以这期间JavaBean可能处于一种不一致的状态，所以在线程相关的情况下，如果在错误的时间调用了这个未完成的JavaBean，将会导致错误，并且该错误和具体发生错误的代码大相径庭，从而极难调试

文中给出了另外一种方式，称之为Builder模式，我个人倒是觉得它算是JavaBean的一个变种吧，即先传入必选参数创建一个a对象，然后再通过类似set方法的方式传入可选参数，但是每次返回的都是Builder对象，最后通过这个Builder对象的全部参数生成一个新的Builder对象，值得一提的是它内部的参数都是final不可变的，这将会使得最后的Builder对象也不可变（全部的参数都是final，无法再次改变），这在安全性上将会好很多，但是不足之处也很明显，因为为了保证它的调用链和安全性，需要牺牲一部分的性能，并且相比于JavaBean无疑代码量复杂很多，所以如何抉择还是需要视情况而定

第三条：用私有构造器或者枚举类型强化Singleton属性

Singleton指仅被实例化一次的类，一般的实现方式有两种，两种均需要把构造器保持为私有，并且把成员设置为final，只是导出公有的静态成员方式不同，一者将该成员公有化，以便外部访问，二者将该成员私有，但是提供一个get方法以访问，前者实现较为简单，但后者对于某些情况的扩展性会更好

但是两种方式都存在一个问题，即反序列化时，会创建一个新的实例，这将导致一定程度上破坏Singleton属性，而为了保证Singleton，之前提到的成员需要声明transient属性以保证其不被序列化，但是与此同时需要加入一个readResolve方法以保证其能顺利通过整个序列化流程

文中提到了第三种方法，即枚举，实现起来十分简单，只需要创建一个枚举类型即可，功能上和之前的方式相近，但是更为简洁易懂且自身提供序列化机制，文中认为它是目前实现Singleton的最佳方式

第四条：通过私有构造器强化不可实例化的能力

简而言之，有些工具类只是提供一些静态方法和静态域，它不需要被实例化，但是如果不加构造方法，它会默认有一个无参的构造方法，这种情况下可以写一个私有的构造方法，使其不能被外部所调用，不过缺点是它不能被子类化，因为它的子类没有可访问的超类的构造器

第五条：避免创建不必要的对象

没啥解释的，说白了就是对于没有必要创建多个对象的情况下，尽量复用对象，这样对于代码的复杂度，维护成本等等都有好处，但也无需吹毛求疵

第六条：消除过期的对象引用

其实该条说的就是OOM，即内存泄漏的问题，现代jvm的垃圾回收机制已经比较完善了，排除确实因为需要，占用过大超过内存容量的情况，一般出现内存泄漏都是因为当对象使用完毕后，仍然保持着对它的强引用，导致jvm无法判断出它是否能够被回收，从而挤占内存，所以消除过期的对象引用是很有必要的。当然毕竟OOM也是一个经久不衰的话题，扩展起来还是很复杂的

第七条：避免使用终结方法

理解起来其实有点复杂，但是总结起来就是除非作为安全网，或是为了终结非关键的本地资源，否则不要使用终结方法，如果用了，那么记住调用super.finalize，如果作为安全网，需要记录终结方法的非法用法

第八条：覆盖equals时请遵守通用约定

本条中大篇幅的写了覆盖equals需要注意的一些约定：自反性；对称性；传递性；一致性；以及equals（null）时必须返回null，但是其实很多内容可以给我们在别的方面带来一些思考

在我们重写一些使用广泛的方法时，或是封装一些接口时，格局应该尽量扩大，保证其基本的一些必有的属性，并且在做完之后反复验证，但是不要企图将他们做的过于智能，过于细枝末节，往往这会带来很多问题，而有很多问题甚至是一时难以发现的，这会给后面调用或者实现的类带来极大的麻烦

第九条：覆盖equals时总要覆盖hashCode

如果覆盖了equals方法后，必须覆盖hashCode方法，如果不这样做的话，在具体类应用到基于hashCode的集合的时候，会因为违反了Java内部的机制（即equals相同的两个对象的hash code不同），这将导致无法使用get方法获取到put存入的值，造成问题，但需要注意的是即使重写hashCode也应该遵照一定方法去生成hash code，而不是写死某一个值，例如10，这将会导致散列表退化为链表，造成很大的影响，散列函数应该遵照“为不相等的对象产生不相等的hash code”的准则来写

第十条：始终要覆盖toString

在Object中有定义toString方法，所以所有对象都会有其toString方法，该方法的默认返回值是getClass.getName()+'@'+Integer.toHexString(hashCode())这会使得很多你期待使用toString看到的对象的值变成你非常不期望看到的那样，例如PhoneNumber@163b91，这乍一看谁知道具体的PhoneNumber类型的值到底是多少呢？所以文中所说覆盖toString的意思即默认的toString方法可能不能很好的满足需求，所以如果有字符串导出的操作，或者是有这方面的需求，强烈建议覆盖他，并且以一个格式良好且有注释的方式来导出值，这样将会使toString的使用体验良好许多

值得一提的是，String，int等基本类型中应该是覆盖了toString方法，他们返回的值是该内容的字符串表示，所以我们在一个基本类型值的后面调用toString，不会出现类似PhoneNumber@163b91的情况

第十一条：谨慎地覆盖clone

这部分确实没有什么好说的，只是说明实现Cloneable接口很多情况下会需要去重写clone方法

文中给出了一些设计clone需要注意的事项，不过最终还是建议，最好的方式就是不要去实现该接口，因为该接口的扩展性非常差，问题很多，除非是拷贝数组

对于一个专门为了继承而设计的类，如果你未能提供行为良好的受保护的clone方法，它的子类就不可能实现Cloneable接口

第十二条：考虑实现Comparable接口

如果需要一些特殊的对比方式来进行特定需求的排序，请实现Comparable接口，实现后需要重写CompareTo方法，类似第八条所说的equals，重写CompareTo也建议遵照一定的约定

另外需要注意的是CompareTo并非每次都要将所有的数据进行对比

假设说需要对同年级的所有学生排序

1班13号和3班15号

最重要的域首先是班级，当1班和3班已经存在某种顺序关系了之后，结果已经显而易见，则无需再对比学号，直接返回结果即可，这样在性能上会好很多

其次就是越界问题，举个最简单的例子，一个int并不能表示所有（int-int）的结果，而最终是扩展储存类型，还是对输入值进行约束则取决于具体需求

第十三条：使类和成员的可访问性最小化

其实说的就是访问级别方面的封装的概念，这样做的好处一方面是将各功能实现尽量模块化，在解耦方面会有优势，其次也便于测试，没有太多好说的，引用一段文中内容吧

总而言之，你应该始终尽可能地降低可访问性。你在仔细地设计了一个最小的公有API之后，应该防止把任何散乱的类，接口和成员变成API的一部分。除了公有静态final域的特殊情况之外，公有类都不应该包含公有域。并且要确保公有静态final域所引用的对象都是不可变的

第十四条：在公有类中使用访问方法而非公有域

其实也是封装的概念，将内部数据隐藏，但提供公有方法供外界访问，这样只要以后方法名不做修改，类的功能的具体实现或者数据的具体修改不会影响其他类的功能实现

第十五条：使可变性最小化

要看懂这一条，首先我们要知道可变类和不可变类的区别

对于一个普通的可变类而言，我们可以给他任意次赋值，这个对象不会改变（或许应该说它的地址不会被改变）但是它的值会改变，而java是面向对象的语言，所以其他类跟该对象的交互其实是持有了该对象的引用（或者说地址），看起来好像有点绕且没有什么影响，但是实际上，假设说我现在新建一个HashSet，里面插入一个可变类的值，我们已知StringBuilder类是可变类

//新建一个HashSet
HashSet hashSet = new HashSet();
//新建一个可变类StringBuffer对象a
StringBuffer a = new StringBuffer("s");
//把a加入到HashSet中
hashSet.add(a);
//新建一个可变类StringBuffer对象b，我希望b的值与a相同，所以把a的值赋值给b
StringBuffer b = a;
//我希望b的值再多加一个s字符
b.append("s");
//我想输出一下hashSet的值，结果发现居然是[ss]？
System.out.println(hashSet);
//回头检查一下a的值，居然也变成了ss
System.out.println(a);

如上述代码所示，我只希望改变一下b的值，但是在StringBuffer b = a这一步中，赋值给b的不是a的值，而是a的地址，b引用的那个地址变成了a的地址，所以给b赋值就变成了给a赋值

即程序员可能并不想修改这个对象的值，但是因为不小心对该对象的调用和赋值，导致改变了该对象的值

当然这个问题的话，可能有人说调用的时候自己注意一下就是了，但是可变类在其他方面也会带来很多负面影响

例如说在多线程，并发的情况下，由于可能存在多个线程同时调用一个对象的情况，导致该对象的数值会变得难以预测并且不符合预期，为了保护它的安全，我们需要使他同步，或是做其他的操作。而不可变类的对象由于其值不可变，所以每次调用后，获得的都是另外一个对象，例如String，我们知道它是不可变的，每次赋值的操作都是新建一个String，然后把该对象的地址赋值给它，所以对于String来说，它是线程安全的，不必为了保护它的数据安全而去做额外的操作和编写额外的代码，当然，不可变类有它的缺点，就是大量数据情况下，会极度消耗资源，毕竟每一次赋值都需要创建两个新对象，所以可以对某些域放宽条件或是编写一个可变配套类，例如String的可变配套类StringBuffer

至于如何让类变成不可变类，书中给出的最优方法是将域（变量）变成private且final的，并且将构造器变为private的，使用静态工厂方法来创建对象。这样相比于final类，可扩展性会好很多。而即使是可变类，也尽量使得能够不可变的域不可变，这样可以减少很多麻烦。

不可变类的规则归根结底只有一句话：没有一个方法能够对对象的状态产生外部可见的改变

第十六条：复合优先于继承

首先我们要明白继承，继承是很强大的，但是它也会带来诸多问题，因为你可能在不清楚继承的父类的功能的具体实现而重写了其方法，例如你重写了父类方法a，但是父类方法b的实现也是依靠了其自身方法a，这将会导致你可能只想改变a，但是ab都被改变了，这种情况下，文中提出了复合的方式

复合即先使用一个类A（转发类）继承父类接口，定义一个父类对象，然后在重写方法中return父类对象的方法的结果，然后用类B（扩展类）去继承类A，随意重写类A的方法，不会对其他类A的方法造成影响，因为它所做的只是将父类方法产生的结果转发出去，类B无法去重写父类的方法，也可以变相理解为类A使得父类的方法互相“解耦”，使其互不影响（因为类A方法return的值是其中父类对象的方法的结果），使得任意方法的预期结果不会因为重写另外一个方法而改变

当然，这会使得类的数量急剧增加，类之间的关系斑驳复杂，代码更难阅读（逻辑关系更加复杂），所以是否使用需要视情况而定

第十七条：要么为继承而设计，并提供文档说明，要么就禁止继承

其实这条算是对前面几条的补充，我们知道如果错误的或者说不当的继承了一个类，那么带来的后果是难以预料的，所以假设说一个类为了继承而设计，那么请提供对应的文档说明，至于并非为了安全地进行子类化而设计和编写的类，请禁止子类化，如之前条目所说，有两种方式比较合适，最简单的就是声明该类为final，另一种是将构造器变成私有的，并且增加公有的静态方法来替代构造器

第十八条：接口优于抽象类

从使用上来说，抽象类肯定更为好用，但考虑到扩展性，抽象类会造成诸多问题，举个栗子：类只能有一个父类，所以如果类在功能增多的情况下，会对这个抽象类造成很大的压力，因为它需要做很多的修改，这带来代码行数的增加，从而可能引发其他问题，但并非抽象类不可取，它作为基类，只要基本功能实现，结构清晰，可以对子类进行有效的约束，但需要保证其职责清晰，功能明确，只单说扩展性的话，必然是接口优于抽象类

第十九条：接口只用于定义类型

如果使用接口来定义常量（其实我们一般也不这样做），一方面如果后期常量有修改，需要修改接口，但是这违背了接口的原则，二则文件量增多，导致维护成本增加，三则难以明确定义，远远不如常量工具类或者枚举清晰方便

PS：二进制兼容性：在升级或修改库文件（这里指的是接口文件），不必重写编译该库的可执行文件（该接口的实现类），其功能不会被破坏

第二十条：类层次优于标签类

文中的标签类大体上指的是类似于定义一类事物的类，举个栗子，定义一个动物类，而动物又分鸟类，虫类等等，动物类囊括了多种子类型，但是它却被集成在了一个类里，类似于我们书中的标签一样

其实文中对标签类的差评个人认为可以理解为解耦的一种思路，当一个类能够实现多个分支的功能，或是定义时，这个类就应该被拆分成多个类或者是分出接口然后做出多个实现类，例如我们可以定义一个图形类或是接口，再去定义圆形方形等子类或是实现类，而不是在一个类中把他们全部做到，即文中所述的标签类。标签类将会使得自身难以维护，并且容易出错

第二十一条：用函数对象表示策略

主要是解决复用的问题，类似Math类，它的所有实例在功能上都是等价的，所以它们作为单例来说是十分合理的

当一个具体策略只被使用一次时，通常使用匿名类来声明和实例化这个具体策略类。当一个具体策略是设计用来重复使用的时候，它的类通常就要被实现为私有的静态类成员，并通过公有的静态final域被导出，其类型为该策略接口

即使使用接口定义，每次使用的时候都需要创建一个新的实例，所以将其定义为静态，且加以保护，保证其单例，使用时以类名.域名.方法名即可

第二十二条：优先考虑静态成员类

这一条主要是一些概念，直接引用部分正文内容吧

如果嵌套类的实例可以在它外围类的实例之外独立存在，这个嵌套类就必须是静态成员类：在没有外围实例的情况下，想要创建非静态成员类的实例是不可能的

如果声明成员类不要求访问外围实例，就要始终把static修饰符放在它的声明中，使它成为静态成员类，而不是非静态成员类。如果省略了static修饰符，则每个实例都将包含一个额外的指向外围对象的引用。保存这份引用要消耗时间和空间，并且会导致外围实例在符合垃圾回收时却仍然得以保留

如果一个嵌套类需要在单个方法之外任然是可见的，或者它太长了，不适合于放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的；否则，就做成静态的。假设这个嵌套类属于一个方法的内部，如果你只需要在一个地方创建实例，并且已经有了一个预置的类型可以说明这个类的特征，就要把它做成匿名类；否则，就做成局部类

第二十三条：请不要在新代码中使用原生态类型

其实这条主要是说了一些泛型的优势，和不应该使用原生态类型的原因

如果使用原生态类型，就失掉了泛型在安全性和表述性方面的所有优势

泛型的作用非常广泛，尤其是在定义接口中的数据类型时，使用泛型的可扩展性都非常好

第二十四条：消除非受检警告

总而言之，非受检警告很重要，不要忽略它们。每一条警告都表示可能在运行时跑出ClassCastException异常。要尽最大的努力消除这些警告。

第二十五条：列表优先于数组

数组是协变的，即如果Sub是Super的子类，那么数组类型Sub[]就是Super[]的子类型。相反泛型则是不可变的，对于任意两个不同的类型，List与List没有任何子类超类的关系，这意味着数组存在缺陷

数组是具体化的，因此数组会在运行时才知道并检查它们的元素类型约束。泛型则是通过擦除来实现的，因此泛型只在编译时强化它们的类型信息，并在运行时丢弃（或者擦除）它们的元素类型信息。

这导致的结果就是，假设说我们要将一个String放入Long容器中，我们都知道这是不合法的，但是最终的结果是

Object[] objectArray = new Long[1];
objectArray[0] = "heheda";

List