目录：
一、创建和销毁对象 （1 ~ 7）
二、对于所有对象都通用的方法 （8 ~ 12）
三、类和接口 （13 ~ 22）
四、泛型 （23 ~ 29）
五、枚举和注解 （30 ~ 37）
六、方法 （38 ~ 44）
七、通用程序设计 （45 ~ 56）
八、异常 （57 ~ 65）
九、并发 （66 ~ 73）
十、序列化 （74 ~ 78）
正文：
第一章： 创建和销毁对象
1、考虑用静态工厂方法代替构造器
优：
① 有名称
② 不必在每次调用它们的时候都创建一个对象
③ 可以放回原返回类型的任何子类型的对象
④ 在创建参数化类型实例的时候，代码更简洁
缺：
① 类如果不含公有的或受保护的构造器，就不能被子类化
② 与其他一般的静态方法无多大区别
2、 遇到多个构造器参数时要考虑用构造器
3、用私有构造器或者枚举类型强化 Singleton 属性
4、通过私有构造器强化不可实例化的能力
5、避免创建不必要的对象
6、消除过期的对象引用
7、避免使用终结方法
第二章： 对于所有对象都通用的方法
8、覆盖 equals 时请遵守通用约定
① 类的每个实例本质上是唯一的
② 不关心类是否提供了“逻辑相等”的测试功能
③ 超类已经覆盖了 equals， 从超类继承过来的行为对于子类也是合适的
④ 类是私有的或包级私有的，可以确定它的 equals 方法永远不会被调用
实现高质量 equals 方法诀窍：
① 使用 “==”操作符检查“参数是否为这个对象的引用”
② 使用 instanceof 操作符检查“参数是否为正确的类型”
③ 把参数转换为正确的类型
④ 对于该类中的每个“关键”域，检查参数中的域是否参与该对象中的对应的域相匹配
⑤ 当你编写完成了 equals 方法之后，应该判断其是否满足了 对称性、传递性、一致性
-
-
- 覆盖 equals 时总要覆盖 hashCode
- 不要企图让 equals 方法过于智能
- 不要将 equals 声明中的 Object 对象器替换为其他的类型
-
9、覆盖 equals 时总要覆盖 hashCode
10、始终要覆盖 toString
11、谨慎地覆盖 clone
12、考虑实现 Comparable 接口
第三章：类和接口
13、使类和成员的可访问性最小化
14、在公有类中使用访问方法而非公有域
15、使可变性最小化
① 不要提供任何会修改对象状态的方法
② 保证类不会被扩展
③ 使所有的域都是 final 的
④ 使所有的域都成为私有的
⑤ 确保对于任何可变组件的互斥访问
16、复合优先于继承
简而言之，继承的功能非常强大，但是也存在诸多问题，因为它违背了封装原则。只有当子类和超类之间确实存在子类类型关系时，使用继承才是恰当的。即便如此，如果子类和超类处在不同的包中，并且超类并不是为了继承而设计的，那么继承将会导致脆弱性。为了避免，可以用复合和转发机制来代替继承，尤其是当存在适合的接口可以实现包装类的时候。包装类不仅比子类更加健壮，而且功能也更加强大。
17、要么为继承而设计，并提供文档说明，要么就禁止继承
18、接口优于抽象类
① 现有的类可以很容易被更新，以实现新的接口
② 接口的定义的理想选择
③ 接口允许我们构造非层次结构的类型框架
接口通常是定义允许多个实现的类型的最佳途径。这条规律有个例外，即当演变的容易性比灵活性和功能更为重要的时候。在这种情况下，应该使用抽象类来定义类型，但前提是必须理解并且可以接受这些局限性。如果你导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类。最后，应该尽可能谨慎的设计所有的公有接口，并通过编写多个实现类对它们进行全面的测试。
19、接口只用于定义类型
接口应该只被用来定义类型，它们不应该被用来导出常量。
20、类层次优于标签类
标签类很少有适用的时候。当你想要编写一个包含显示标签域的类时，应该考虑一下，这个标签是否可以被取消，这个类是否可以用类层次来代替。当你遇到一个包含标签域的现有类时，就要考虑将它重构到一个层次结构中去。
21、用函数对象表示策略
要声明一个接口来表示该策略，并且为每个具体策略声明一个实现了该接口的类。当一个具体策略只被使用一次时，通常实现匿名类来声明和实例化这个具体策略类。当一个具体策略类是设计用来重复使用的时候，它的类通常就要被实现为私有的静态成员类，并通过公有的静态 final 域被导出，其类型为该策略接口。
22、优先考虑静态成员类
静态成员类、非静态成员类、匿名类、局部类
① 如果一个嵌套类需要在单个方法之外仍然是可见的，或者他太长了，不适合于放在内部，就应该使用成员类。
② 如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的；否则就做成静态的。
③ 假设这个嵌套类属于一个方法的内部，如果你只需要在一个地方创建实例，并且已经有一个预置的类型可以说明这个类的特征，就要把它做成匿名类；否则，就做成局部类。
第四章 泛型
23、请不要在新代码中使用原生态类型
24、消除非受检警告
每一条警告都表示可能在运行时片抛出 ClassCastException 异常。要尽最大的努力消除这些警告。如果无法消除非受检警告，同时可以证明引起警告的代码是类型安全的，就可以在尽可能小的范围中，用 @SuppressWarnings("unchecked")注释禁止该警告。要用注释把禁止该警告的原因记录下来。
25、列表优先于数组
数组和泛型有着非常不同的类型规则。数组是协变且可以具体化的；泛型是不可变的且可以被擦除的。因此数组提供了运行时的类型安全，当时没有编译时的类型安全，反之，对于泛型也一样。一般来说，数组和泛型不能很好地混合使用。如果你发现自己将它们混合起来使用，并且得到了编译时错误或警告，应该用列表代替数组。
26、优先考虑泛型
27、优先考虑泛型方法
28、利用有限制通配符来提升API 的灵活性
29、优先考虑类型安全的异构容器
第六章 枚举和注解
30、用 enum 代替 int 常量
31、用实例域代替序数
32、用 EnumSet 代替位域
33、用 EnumMap 代替序数索引
34、用接口模拟可伸缩的枚举
35、注解优先于命名模式
36、坚持使用 Override 注解
37、用标记接口定义类型
第七章 方法
38、检查参数的有效性
39、必要时进行保护性拷贝
40、谨慎设计方法签名
① 谨慎地选择方法的名称
② 不要过于追求提供便利的方法
③ 避免过长的参数列表
41、慎用重载
“能够重载方法”并不意味着就“应该重载方法”。一般情况下，对于多个具有相同参数数目的方法来说，应该尽量避免重载方法。在某些情况下，特别是涉及构造器的时候，要遵循这条建议也许是不可能的。在这种情况下，至少应该避免这样的情形：同一组参数只需经过类型转换就可以被传递给不同的重载方法。
42、慎用可变参数
43、返回零长度的数组或者集合，而不是 null
44、未所有导出的 API 元素编写文档注释
第八章 通用程序设计
45、将局部变量的作用域最小化
46、for-each 循环优先于传统的 for 循环（除了 在过滤、转换、平行迭代下外）
47、了解和使用类库
48、如果需要精确的答案，请避免使用 float 和 double
49、基本类型优先于装箱基本类型
50、如果其他类型更适合，则尽量避免使用字符串
① 字符串不适合代替其他的值类型
② 字符串不适合代替枚举类型
③ 字符串不适合代替聚集类型
④ 字符串不适合代替能力表
51、当心字符串连接的性能
52、通过接口引用对象
53、接口优先于反射机制
反射的不足：
① 丧失了编译时类型检查的好处
② 执行反射访问所需要的代码非常笨拙和冗长
③ 性能损失
54、谨慎使用本地方法
55、谨慎地进行优化
56、遵守普遍接受的命名惯例
第九章 异常
57、只针对异常的情况才使用异常
58、对于可恢复的情况使用受检异常，对于编程错误使用运行时异常
59、避免不必要地使用受检的异常
60、优先使用标准的异常
61、抛出与抽象相对应的异常
62、每个方法抛出的异常都要有文档
63、在细节消息中包含能捕获失败的信息
64、努力使失败保持原子性
65、不要忽略异常
第十章 并发
66、同步访问共享的可变数据
67、避免过度同步
为了避免死锁和数据破坏，千万不要从同步区域内部调用外来方法。更为一般地讲，要尽量限制同步区域内部的工作量。
68、executor 和 task 优先于线程
69、并发工具优先于 wait 和 notify
70、线程安全性的文档化
71、使用延迟初始化
72、不要依赖于线程调度器
73、避免使用线程组
第十一章 序列化
74、谨慎地实现 Serializable 接口
使用此接口代价：
① 一旦一个雷被发布，就大大降低了“改变这个类的实现”的灵活性
② 增加了出现 Bug和安全漏洞的可能性
③ 随着类发行新的版本，相关的测试负担也增加了
75、考虑使用自定义的序列化形式
使用默认序列化形式缺点：
① 它使这个类的导出 API 永远地束缚在该类的内部表示法上
② 它会消耗过多的空间
③ 它会消耗过多的时间
④ 它会引起栈溢出
76、保护性地编写 readObject 方法
77、对于实例控制，枚举类型优先于 readResolve
78、考虑用序列化代理代替序列化实例
来源：https://www.cnblogs.com/jesonjason/p/5824001.html