第 1 条：用静态工厂方法替代构造器
优点：静态工厂它们有名称。 如果构造器的参数本身没有确切地描述正被返回的对象，那么具有适当名称的静态工厂会更容易使用，产生的客户端代码也更易于阅读；不必在每次调用它们的时候都创建一个新对象。不可变类可以使用预先构建好的实例，或者将构建好的实例缓存起来，进行重复利用，从而避免创建不必要的重复对象；静态工厂可以返回原返回类型的任何子类型的对象。这样我们在选择返回对象的类时就有了更大的灵活性；所返回的对象的类可以随着每次调用而发生变化，这取决于静态工厂方法的参数值；方法返回的对象所属的类，在编写包含该静态工厂方法的类时可以不存在
缺点：静态工厂方法的主要缺点在子，类如果不含公有的或者受保护的构造器，就不能被子类化 。 例如，要想将 Collections Framework 中的任何便利的实现类子类化 ， 这是不可能的 。但是这样也许会因祸得福，因为它鼓励程序员使用复合（ composition ），而不是继承，这正是不可变类型所需要的。静态工厂方法的第二个缺点在于，程序员很难发现它们 。
第 2 条：遇到多个构造器参数时要考虑使用构建器
重叠构造器模式可行，但是当有许多参数的时候，客户端代码会很难缩写，并且仍然较难以阅读。构建器不直接生成想要的对象，而是让客户端利用所有必要的参数调用构造器（或者静态工厂），得到一个 builder 对象。然后客户端在 builder 对象上调用类似于 setter 的方法，来设置每个相关的可选参数 。 最后客户端调用无参的 build 方法来生成通常是不可变的对象。
为了创建对象 ，必须先创建它 的构建器 。 虽然创建这个构建器的开销在实践中可能不那么明显 但是在某些十分注重性能的情况下，可能就成问题了 。 Builder 模式比重叠构造器模式更加冗长 ，因此它只在有很多参数的时候才使用，比如4个或者更多个参数 。 但是记住，将来你可能需要添加参数。 如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构造器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调 。 因此，通常最好一开始就使用构建器 。简而言之 ， 如果类的构造器或者静态工厂中具有多个参数，设计这种类时， Builder模式就是一种不错的选择， 特别是当大多数参数都是可选或者类型相同的时候 。 与使用重叠构造器模式相比，使用 Bui lder 模式的客户端代码将更易于阅读和编写，构建器也比JavaBeans 更加安全 。
第 3 条：用私有构造器或者枚举类型强化 Singleton 属性
单元素的枚举类型经常成为实现 Singleton 的最佳方法。注意，如果 Singleton必须扩展一个超类，而不是扩展 Enum的时候，则不宜使用这个方法。
第 4 条：通过私有构造器强化不可实例化的能力
工具类不希望被实例化，因为实例化对它没有任何意义 。然而，在缺少显式构造器的情况下，编译器会自动提供一个公有的、无参的缺省构造器（ default constructor ）。对于用户而言，这个构造器与其他的构造器没有任何区别。
第 5 条：优先考虑依赖注人来引用资源
不要用 Singleton 和静态工具类来实现依赖一个或多个底层资源的类，且该资源的行为会影响到该类的行为 ；也不要直接用这个类来创建这些资源 。 而应该将这些资源或者工厂传给构造器（或者静态工厂，或者构建器），通过它们来创建类 。 这个实践就被称作依赖注入，它极大地提升了类的灵活性 、 可重用性和可测试性 。
第 6 条：避免创建不必要的对象
例如不必每次使用new String("str")或者在校验正则表达式的时候不使用String的matches方法，因为该方法每次都会new一个Pattern对象。
自动装箱使得基本类型和装箱基本类型之间的差别变得模糊起来，但是并没有完全消除 。所以要优先使用基本类型而不是装箱基本类型，要当心无意识的自动装箱。
第 7 条：消除过期的对象引用
第 8 条：避免使用终结方法和清除方法
终结方法（ finalize）通常是不可预测的，也是很危险的，一般情况下是不必要的 。 使用终结方法会导致行为不稳定 、 性能降低，以及可移植性问题。 当然，终结方法也有其可用之处，我们将在本条目的最后再做介绍；但是根据经验，应该避免使用终结方法 。 在 Java 9中用清除方法（ cleaner）代替了终结方法 。 清除方法没有终结方法那么危险，但仍然是不可预测、运行缓慢，一般情况下也是不必要的 。
第 9 条： try-with-resources 优先于 try-finally
代码将更加简洁、清晰，产生的异常也更有价值，如果调用 readLine 和close方法都抛出异常，后一个异常就会被禁止，以保留第一个异常 。 事实上，为了保留你想要看到的那个异常，即便多个异常都可以被禁止。这些被禁止的异常并不是简单地被抛弃了，而是会被打印在堆栈轨迹中，并注明它们是被禁止的异常。
第 10 条：覆盖 equals 时请遵守通用约定
自反性（ reflexive ） ： 对于任何非 null 的引用值 x x . equals(x ）必须返回 true 。
对称性（ symmetric ）：对于任何非 null 的引用值 x 和 y ，当且仅当 y.equals(x ）返回true 时， x.equals(y ）必须返回 true 。
传递性（ transitive ）：对于任何非 null 的引用值 x 、 y 和 z ，如果 x.equals(y ）返回
true ，并且 y.equals(z ）也返回 true ，那么 x.equals(z ）也必须返回 true 0
一致性（ consistent ） ： 对于任何非 nu ll 的 引用值 x 和 y ，只要 equals 的比较操作
在对象中所用的信息没有被修改，多次调用 x.equals(y ）就会一致地返回 true,或者一致地返回 false
1. 使用＝＝操作符检查“参数是否为这个对象的引用” 。 如果是，则返回 true 。 这只不过是一种性能优化，如果比较操作有可能很昂贵，就值得这么做。
2 . 使用 instanceof 操作符检查“参数是否为正确的类型” 。 如果不是，则返回 false ,一般说来，所谓“正确的类型”是指 equals 方法所在的那个类 。 某些情况下，是指该类所实现的某个接口 。 如果类实现的接口改进了equals 约定，允许在实现了该接口的类之间进行比较，那么就使用接口 。 集合接口如 Set 、 List 、 Map 和 Map . Entry 具有这样的特性 。
3. 把参数转换成正确的类型 。 因为转换之前进行过且 instance of 测试，所以确保会成功 。
4 . 对于该类中的每个“关键”域，检查参数中的域是否与该对象中对应的域相匹配 。 如果这些测试全部成功， 则返回 true ；否则返回 false 。 如果第 2 步中的类型是个接口，就必须通过接口方法访问参数中的域；如果该类型是个类，也许就能够直接访问参数中的域，这要取决于它们的可访问性 。
覆盖 equals 时总要覆盖 hashCode方法
不要企图让 equals 方法过于智能。如果只是简单地测试域中的值是否相等，则不难做到遵守 equals 约定 。 如果想过度地去寻求各种等价关系， 则很容易陷入麻烦之中 。 把任何一种别名形式考虑到等价的范围内，往往不会是个好主意 。
不要将equals声明中的Object对象替换为其他的类型。 问题在于，这个方法并没有覆盖Object. equals ，因为它的参数应该是 Object 类型，相反，它重载（ overload ）了 Object.equals 。 在正常equals 方法的基础上，再提供一个“强类型”的 equals 方法，这是无法接受的，因为会导致子类中的 Override 注解产生错误的正值，带来错误的安全感。
不要轻易覆盖 equals 方法，除非迫不得已。因为在许多情况下，从Object 处继承的实现正是你想要 的 。 如果覆盖 equals ，一定要比较这个类的所有关键域。
第 11 条：覆盖 equals 时总要覆盖 hashCode
相等的对象必须具有相等的散列码(hash code),覆盖equals不覆盖hashCode，会导致程序将无法正确运行。 hashCode方法必须遵守Object规定的通用约定，并且必须完成一定的工作，将不相等的散列码分配给不相等的实例。这个很容易实现，但是如果不想那么费力，可以使用Objects的hash方法。
第 12 条：始终要覆盖 toString
toString 方法应该返回对象中包含的所有值得关注的信息，
第 13 条 ： 谨慎地覆盖 clone
实际上， clone 方法就是另一个构造器；必须确保它不会伤害到原始的对象，并确保正确地创建被克隆对象中的约束条件。总之，复制功能最好由构造器或者工厂方法提供 。 这条规则最绝对的例外是数组，最好利用 clone 方法复制数组。
第 14 条：考虑实现 Comparable 接口
由 compare To 方法施加的等同性测试，也必须遵守相同于 equals 约定所施加的限制条件：自反性 、 对称性和传递性
每当实现一个对排序敏感的类时，都应该让这个类实现 Comparable接口，以便其实例可以轻松地被分类 、 搜索，以及用在基于比较的集合中 。 每当在 compareTo 方法的实现中比较域值时，都要避使用 ＜ 和＞操作符，而应该在装箱基本类型的类中使用静态的 compare 方法，或者在 Comparator 接口中使用比较器构造方法 。
第 15 条：使类和成员的可访问性最小化
信息隐藏可以有效地解除组成系统的各组件之间 的藕合关系，即解耦，使得这些组件可以独立地开发、 测试、优化 、使用、理解和修改 。 因为这些组件可以并行开发，所以加快了系统开发的速度 。 同时减轻了维护的负担，程序员可以更快地理解这些组件，并且在调试它们的时候不影响其他的组
件。 信息隐藏提高了软件的可重用性，因为组件之间并不紧密相连，除了开发这些模块所使用的环境之外，它们在其他的环境中往往也很有用 。 最后，信息隐藏也降低了构建大型系统的风险，因为即使整个系统不可用，这些独立的组件仍有可能是可用的 。
如果方法覆盖了超类中的一个方法，子类中的访问级别就不允许低于超类中的访问级别。这样可以确保任何可使用超类的实例的地方也都可以使用子类的实例。
公有类的实例域决不能是公有的。 如果实例域是非final 的，或者是一个指向可变对象的 final 引用， 那么一旦使这个域成为公有的，就等于放弃了对存储在这个域中的值进行限制的能力；这意味着，你也放弃了强制这个域不可变的能力 。 同时，当这个域被修改的时候，你也失去了对它采取任何行动的能力 。 因此， 包含公有可变域的类通常并不是线程安全的 。 即使域是 final 的，并且引用不可变的对象，但当把这个域变成公有的时候，也就放弃了“切换到一种新的内部数据表示法”的灵活性 。
第 16 条：要在公有类而非公有域中使用访问方法
公有类永远都不应该暴露可变的域。 虽然还是有问题，但是让公有类暴露不可变的域，其危害相对来说比较小 。 但有时候会需要用包级私有的或者私有的嵌套类来暴露域，无论这个类是可变的还是不可变的 。
第 17 条：使可变性最小化
不可变类是指其实例不能被修改的类,例如String
为了使类成为不可变，要遵循下面五条规则：
1. 不要提供任何会修改对象状态的方法 （也称为设值方法） 。
2. 保证类不会被扩展。这样可以防止粗心或者恶意的子类假装对象的状态已经改变，从而破坏该类的不可变行为 。 为了防止子类化，一般做法是声明这个类成为 final。
3. 声明所有的域都是final的 。通过系统的强制方式可以清楚地表明你的意图 。 而且，如果一个指向新创建实例的引用在缺乏同步机制的情况下，从一个线程被传递到另一个线程，就必须确保正确的行为。
4 . 声明所有的域都为私有的。这样可以防止客户端获得访问被域引用的可变对象的权限，井防止客户端直接修改这些对象 。 允许不可变的类具有公有的final域，只要这些域包含基本类型的值或者指向不可变对象的引用，但是不建议这样做，因为这样会使得在以后的版本中无法再改变内部的表示法。
5. 确保对子任何可变组件的互斥访问 。 如果类具有指向可变对象的域，则必须确保该类的客户端无法获得指向这些对象的引用。并且，永远不要用客户端提供的对象引用来初始化这样的域，也不要从任何访问方法中返回该对象引用。 在构造器、访问方法和 readObject 方法中使用保护性拷贝。
不可变对象(final Object)本质上是线程安全的，它们不要求同步 。 当多个线程并发访问这样的对象时它们不会遭到破坏 。 这无疑是获得线程安全最容易的办法 。 实际上，没有任何线程会注意到其他线程对于不可变对象的影响。所以，不可变对象可以被自由地共享 。 不可变类应该充分利用这种优势，鼓励客户端尽可能地重用现有的实例 。 要做到这一点，一个很简便的办法就是：对于频繁用到的值，为它们提供公有的静态final常量。
不仅可以共享不可变对象，甚至也可以共享它们的内部信息
不可变对象为其他对象提供了大量的构件 无论是可变的还是不可变的对象。如果知道一个复杂对象内部的组件对象不会改变，要维护它的不变性约束是比较容易的。这条原则的一种特例在于，不可变对象构成了大量的映射键(map key）和集合元素（set element)； 一旦不可变对象进入到映射（ map ）或者集合（ set）中，尽管这破坏了映射或者集合的不变性约束，但是也不用担心它们的值会发生变化。
不可变对象无偿地提供了失败的原子性。 它们的状态永远不变，因此不存在临时不一致的可能性 。
不可变类真正唯一的缺点是， 对于每个不同的值都需要一个单独的对象。 创建这些对象的代价可能很高，特别是大型的对象。除非有令人信服的理由要使域变成是非 fina l 的，否则要使每个域都是 pr ivate final 的 。
第 18 条：复合优先于继承
类依赖于其超类中特定功能的实现细节。超类的实现有可能会随着发行版本的不同而有所变化，如果真的发生了变化，子类可能会遭到破坏，即使它的代码完全没有改变。 因而，子类必须要跟着其超类的更新而演变，除非超类是专门为了扩展而设计的。
在新的类中增加一个私有域，它引用现有类的一个实例 。 这种设计被称为“复合”。
第 19 条：要么设计继承并提供文档说明，要么禁止继承
如果不这么做，子类就会依赖超类的实现细节，如果超类的实现发生了变化，它就有可能遭到破坏 。 为了允许其他人能编写出高效的子类，还你必须导出 一个或者多个受保护的方法 。 除非知道真正需要子类，否则最好通过将类声明为 final ，或者确保没有可访问的构造器来禁止类被继承。
第 20 条：接口优于抽象类
第 21 条 ： 为后代设计接口
第 22 条：接口只用于定义类型
常量接口模式是对接口的不良使用，类在内部使用某些常量，这纯粹是实现细节。实现常量接口会导致把这样的实现细节泄露到该类的导出 API 中 。这样做反而会使客户端更加糊涂。可以使用枚举代替
第 23 条 ： 类层次优于标签类
第 24 条 ： 静态成员类优于非静态成员类
静态成员类可以访问外围类的所有成员，包括那些声明为私有的成员 。 静态成员类是外围类的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则 。 如果它被声明为私有的，它就只能在外围类的内部才可以被访问。
非静态成员类的每个实例都隐含地与外围类的一个外围实例相关联 。 在非静态成员类的实例方法内部，可以调用外围实例上的方法，构造获得外围实例的引用。 如果嵌套类的实例可以在它外围类的实例之外独立存在，这个嵌套类就必须是静态成员类：在没有外围实例的情况下，要想创建非静态成员类的实例是不可能的 。当非静态成员类的实例被创建的时候，它和外围实例之间的关联关系也随之被建立起来；而且，这种关联关系以后不能被修改。 通常情况下，当在外围类的某个实例方法的内部调用非静态成员类的构造器时，这种关联关系被自动建立起来 。
匿名类不是外围类的一个成员。它并不与其他的成员一起被声明，而是在使用的同时被声明和实例化 。 匿名类可以出现在代码中任何允许存在表达式的地方 。 当且仅当匿名类出现在非静态的环境中时，它才有外围实例 。 但是即使它们出现在静态的环境中，也不可能拥有任何静态成员，而是 final 类型，或者被初始化成常量表达式的字符串域 。匿名类的运用受到诸多的限制 。 除了在它们被声明的时候之外，是无法将它们实例化的。匿名类的客户端无法调用任何成员。
第 25 条：限制j原文件为单个顶级类
第 26 条：请不要使用原生态类型
如果使用原生态类型，就失掉了泛型在安全性和描述性方面的所有优势，但原生类型可以保证兼容性。
新代码中不要使用原生类型
？表示无限制类型的通配符
第 27 条：消除非受检的警告
非受检警告很重要 ，不要忽略它们 。 每一条警告都表示可能在运行时抛出ClassCastException 异常 。 要尽最大的努力消除这些警告 。 如果无法消除非受检警告，同时可以证明引起警告的代码是类型安全的 就可以在尽可能小的范围内使用＠ Suppress -Warnings （ "unchecked ”）注解禁止该警告 。 要用注释把禁止该警告的原因记录下来 。
第 28 条：列表优于数组
创建泛型数组是非法的，因为它不是类型安全的。要是它合法，编译器在其他正确的程序中发生的转换就会在运行时失败，并出现－个 ClassCastException 异常 。这就违背了泛型系统提供的基本保证。
数组是协变(具有父子类型关系)且可以具体化的；泛型是不可变的且可以被擦除的 。 因此，数组提供了运行时的类型安全，但是没有编译时的类型安全，反之，对于泛型也一样。 一般来说，数组和泛型不能很好地混合使用 。 如果你发现自己将它们混合起来使用，并且得到了编译时错误或者警告，你的第一反应就应该是用列表代替数组。
第 29 条：优先考虑泛型
使用泛型比使用需要在客户端代码中进行转换的类型来得更加安全，也更加容易 。 在设计新类型的时候，要确保它们不需要这种转换就可以使用。这通常意味着要把类做成是泛型的 。 只要时间允许，就把现有的类型都泛型化 。 这对于这些类型的新用户来说会变得更加轻松，又不会破坏现有的客户端。
第 33 条：优先考虑类型安全的异构容器
限制每个容器只能有固定数目的类型参数 。 你可以通过将类型参数放在键上而不是容器上来避开这一限制 。 对于这种类型安全的异构容器，可以用 Class 对象作为键 。 以这种方式使用的 Class 对象称作类型令牌 。 你也可以使用定制的键类型 。 例如，用一个 DatabaseRow 类型表示一个数据库行（容器），用泛型 Column<T＞作为它的键 。
第 34 条 ： 用 enum 代替 int 常量
int 枚举模式不具有类型安全性， 也几乎没有描述性可言 。
String 枚举模式，同样也不是我们期望的。它虽然为这些常量提供了可打印的字符串，但是会导致初级用户直接把字符串常量硬编码到客户端代码中，而不是使用对应的常量字段名 。 一旦这样的硬编码字符串常量中包含书写错误，在编译时不会被检测到，但是在运行的时候却会报错 。 而且它会导致性能问题，因为它依赖于字符串的比较操作。
枚举天生就是不可变的，因此所有的域都应该为 final的
第 35 条：用实例域代替序数
永远不要根据枚举的序数导出与它关联的值，而是要将它保存在一个实例域中。
第 36 条：用 EnumSet 代替位域
第 37 条：用 EnumMap 代替序数索引
第 38 条 ： 用接 口 模拟可扩展的枚举
虽然无法编写可扩展的枚举类型，却可以通过编写接口以及实现该接口的基础枚举类型来对它进行模拟。
第 39 条：注解优先于命名模式
命名模式（ naming pattern）表明有些程序元素需要通过某种工具或者框架进行特殊处理。
第 40 条：坚持使用 Override 注解
如果在你想要的每个方法声明中使用 Override 注解来覆盖超类声明，编译器就可以替你防止大量的错误
第 41 条：用标记接口定义类型
标记接口（ marker interface ）是不包含方法声明的接 口，它只是指明（或者“标明”） 一个类实现了具有某种属性的接口 。 例如，考虑 Serializable 接口。
如果标记是应用于任何程序元素而不是类或者接口，就必须使用注解，因为只有类和接口可以用来实现或者扩展接口。如果标记只应用于类和接口，就应该优先使用标记接口而非注解 。 这样你就可以用接口作为相关方法的参数类型，它可以真正为你提供编译时进行类型检查的好处 。
第 42 条： Lambda 优先于匿名类
因为编译器是从泛型获取到得以执行类型推导的大部分类型信息的 。 如果你没有提供这些信息，编译器就无法进行类型推导，你就必须在 Lambda 中手工指定类型，这样极大地增加了它们的烦琐程度 。 如果上述代码片段中的变量 words 声明为原生态类型 List ，而不是参数化的类型 List<String＞，它就不会进行编译 。
Lambda 没有名称和文档；如果一个计算本身不是自描述 的， 或者超 出了几行， 那就不要把它旋在一个 Lambda中。
第 43 条：方法引用优先于 Lambda
从 Lambda 中提取代码，放到－个新的方法中，并用该方法的一个引用代替 Lambda。 你可以给这个方法起一个有意义的名字，并用自己满意的方式编写进入文档 。
方法引用常常 比 Lambda 表达式更加简洁明了 。 只要方法引用更加简洁、清晰，就用方法引用；如果方法引用并不简洁，就坚持使用 Lambda 。
第 44 条：坚持使用标准的函数接 口
只要标准的函数接口能够满足需求，通常应该优先考虑，而不是专门再构建一个新的函数接口 。 这样会使 API 更加容易学习，通过减少它的概念内容，显著提升互操作性优势，因为许多标准的函数接口都提供了有用的默认方法。
Operator 接口代表其结果与参数类型一致的函数 。 Predicate 接口代表带有一个参数并返回一个 boolean 的函数。 Function 接口代表其参数与返回的类型不一致的函数。Supplier 接口代表没有参数并且返回（或“提供”）一个值的函数 。 最后， Consumer 代表的是带有一个函数但不返回任何值的函数，相当于消费掉了参数。
最好不要用带包装类型的基础函数接口来代替基本函数接口，会导致致命的性能问题 。
第 45 条：谨慎使用 Stream
从 Lambda 则只能读取final或者有效的 final 变量，并且不能修改任何 local 变量