myepicure的专栏

选择错误的序列化形式对于一个类的复杂性和性能都会有永久的负面影响。87.1 如果事先没有认真考虑默认的序列化形式是否合适，则不要贸然接受。如果一个对象的物理表示法等同于它的逻辑内容，可能适合使用默认的序列化形式。即使确定了默认的序列化形式是合适的，通常还必须提供一个readObject方法以保证约束关系和安全性。87.2 当一个对象的物理表示法与它的逻辑数据内容有实质性的区别时，使用默认的序列化形式会有以下4个缺点：a. 它使这个类的导出API永远地束缚在该类的内部表示法上。

在一个被同步的区域内部，不要调用设计成要被覆盖的方法，或者是由客户端以函数对象的形式提供的方法。同步不仅可以阻止一个线程看到对象处于不一致的状态中，它还可以保证进入同步方法或者同步代码块的每个线程，都能看到由同一个锁保护的之前所有的修改效果。类的实例是可变的，但有足够的内部同步，所以不需要外部同步，如AtomicLong和ConcurrentHashMap。不要企图通过调用Thread.yield来“修正”程序，因为这样的程序不可移植，同一个yield调用在不同的JVM实现上是不一样的。

如果不能阻止或者处理来自更低层的异常，一般的做法是使用异常转译，只有在低层方法的规范碰巧可以保证“它所抛出的所有异常对于更高层也是合适的”情况下，才可以将异常从低层传播到高层。使用Javadoc的@throws标签记录下一个方法可能抛出的每个受检异常，但是不要使用throws关键字将未受检的异常包含在方法的声明中。如果一个类中的许多方法出于同样的原因而抛出同一个异常，在该类的文档注释中对这个异常建立文档，这是可以接受的，而不是为每个方法单独建立文档。异常应该只用于异常的情况下，永远不应该用于正常的控制流。

如果编写的程序必须要与编译时未知的类一起工作，如有可能应该仅仅用反射机制来实例化对象，而访问对象时则使用编译时已知的某个接口或者超类。如果不够快，则可以在性能分析器的帮助下，找到问题的根源，然后设法优化系统中相关的部分。优先在类库查找所需功能，如果类库找不到，下一个选择应该是在高级的第三方类库去寻找，如Guava类库。a. 如果需要遍历集合，并删除选定的元素，就需要使用显式的迭代器，以便调用remove方法。a. 可以充分利用这些编写标准类库的专家的知识，以及在你之前的其他人的使用经验。

在定义参数数目不定的方法时，可变参数是一种很方便的方式。在使用可变参数之前，要先包含所有必要的参数，并且要关注使用可变参数所带来的性能影响(因为每次调用可变参数方法都会导致一次数组分配和初始化)。如果拷贝成本受到限制，并且信任它的客户端不会不恰当地修改组件，就可以在文档中指明客户端的职责是不得修改受到影响的组件，以此来代替保护性拷贝。对于公有的和受保护的方法，要用Javadoc的@throws标签在文档中说明违反参数值限制时会抛出的异常。对于重载方法的选择是静态的，要调用哪个重载方法是在编译时决定的。

如果返回的序列足够小，容易存储，或许最好返回标准的集合实现，如ArrayList或者HashSet。对于公共的、返回序列的方法，Collection或者适当的子类型通常是最佳的返回类型。如果一个计算本身不是自描述的，或者超出了几行(一到三行是合理的)，那就不要把它放在一个Lambda中。在编写返回一系列元素的方法时，记住优先返回集合，如果无法返回集合，就返回Stream或者Iterable，方便使用即可。尽量不要并行Stream，除非有足够的理由相信它能保证计算的正确性，并且加快程序的运行速度。

标记接口(marker interface)是不包含方法声明的接口，它只是指明(或标明)一个类实现了具有某种属性(数据)的接口。标记注解(marker annotation)就是使用注解，“标注”被注解的元素。标记接口有两点胜过标记注解：a. 标记接口定义的类型是由被标记类的实例实现的；标记注解则没有定义这样的类型。b. 标记接口可以被更加精确地进行锁定。标记注解的优点在于它们是更大的注解机制的一部分。如果标记是应用于任何程序元素而不是类或者接口，或者用于使用了注解类型的框架。就必须使用注解。

你也可以使用定制的键类型。>是安全的，而Set是不安全的。a. 数组是协变的，如果Sub是Super的子类型，那么Sub[]就是Super[]的子类型；b. 如果无法消除警告，同时可以证明引起警告的代码是类型安全的，才可以用一个@SuppressWarnings("unchecked")注解来禁止这条警告。32.3 如果选择编写带有泛型或者参数化可变参数的方法，首先要确保该方法是类型安全的，然后用@SafeVarargs对它进行注解。因此数组提供了运行时的类型安全，但没有编译时的类型安全，而泛型则相反。

接口应该只被用来定义类型，不应该被用来导出常量。常量应该用不可实例化的工具类或枚举类型来导出。

null && y!14.2 传递性：x.compareTo(y)>0 && y.compareTo(z)>0，then x.compareTo(z)>0。14.4 强烈建议 (x.compareTo(y)==0) == (x.equals(y))

a. 终结方法(finalizer)通常是不可预测的，也是危险的，一般情况下是不必要的。Java9中清除方法(cleaner)没有那么危险，但仍然是不可预测，运行缓慢，一般情况下也是不必要的。不要用Singleton和静态工具类来实现依赖一个或多个底层资源的类，应该将这些资源或者工厂传给构造器，通过它们来创建类，这个实践被称作依赖注入。恶意子类的终结方法，可以将对象的引用记录在一个静态域中，阻止它被垃圾回收。给对象引用赋null。1.5 方法返回的对象所属的类，在编写包含该静态工厂方法的类时可以不存在。