第2条：遇到多个构造器参数时要考虑用构建器
与构造器相比，builder的微略优势在于，builder可以有多个可变(varargs)参数。构造器就像方法一样，只能有一个可变参数。因为builder利用单独的方法来设置每个参数，你想要多少个可变参数，它们就可以有多少个，直到每个setter方法都有一个可变参数。
第6条：消除过期对象引用
一般而言，只要类是自己管理内存，程序员就应该警惕内存泄漏问题。一旦元素被释放掉，则该元素中包含的任何对象引用都应该被清空。
内存泄漏的另一个常见来源是缓存。一旦你把对象引用放到缓存中，它就很容易被遗忘掉，从而使得它不再有用之后很长一段时间内仍然留在缓存中。对干这个问题，有几种可能的解决方案。如果你正好要实现这样的缓存:只要在缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap代表缓存，当缓存中的项过期之后，它们就会自动被删除。记住只有当所要的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。
内存泄漏的第三个常见来源是监听器和其他回调。如果你实现了一个API, 客户端在这个API中注册回调，却没有显式地取消注册，那么除非你采取某些动作，否则它们就会积聚。确保回调立即被当作垃圾问收的最佳方法是只保存它们的弱引用(weak reference。例如，只将它们保存成WeakHashMap中的键。
第7条:避免使用终结方法
注重时间（time-critical）的任务不应该由终结方法来完成。例如，用终结方法来关闭已经打开的文件，这是严重错误，因为打开文件的描述符是一种很有限的资源。
不应该依赖终结方法来更新重要的持久状态。例如，依赖终结方法来释放共享资源(比如数据库)上的永久锁，很容易让整个分布式系统垮掉。
还有点:使用终结方法有一个非常严重的(Severe）性能损失。
那么，如果类的对象中封装的资源(例如文件或者线程)确实需要终止。应该怎么做才能不用编写终结方法呢?只需提供一个显式的终止方法，并要求该类的客户端在每个实例不再有用的时候调用这个方法。
显式的终止方法通常与try-finally结构结合起来使用，以确保及时终止。在finally子句内部调用显式的终止方法，可以保证即使在使用对象的时候有异常抛出，该终止方法也会执行:
那么终结方法有什么好处呢?’它们有两种合法用途。第一种用途是，当对象的所有者忘记调用前面段落中建议的显式终止方法时，终结方法可以充当“安全网（safety net ) "。虽然这样做并不能保证终结方法会被及时地调用，但是在客户端无法通过调用显式的终止方法来正常结束操作的情况下(希望这种情形尽可能地少发生)，迟一点释放关键资源总比永远不释放要好。但是如果终结方法发现资源还未被终止，则应该在日志中记录一条警告，因为这表示客户端代码中的一个bug，应该得到修复。
值得注意的很重要一点是，“终结方法链(Finalizer chaining)”并不会被自动执行。如果类(不是Object）有终结方法，并且子类覆盖了终结方法，子类的终结方法就必须手工调用超类的终结方法。你应该在一个try块中终结子类，并在相应的finally块中调用超类的终结方法。