Effective Java笔记一 创建和销毁对象
Effective Java笔记一 创建和销毁对象
- 第1条 考虑用静态工厂方法代替构造器
- 第2条 遇到多个构造器参数时要考虑用构建器
- 第3条 用私有构造器或者枚举类型强化Singleton属性
- 第4条 通过私有构造器强化不可实例化的能力
- 第5条 避免创建不必要的对象
- 第6条 消除过期的对象引用
- 第7条 避免使用终结方法
第1条 考虑用静态工厂方法代替构造器
对于类而言, 最常用的获取实例的方法就是提供一个公有的构造器, 还有一种方法, 就是提供一个公有的静态工厂方法(static factory method), 返回类的实例.
(注意此处的静态工厂方法与设计模式中的工厂方法模式不同.)
提供静态工厂方法而不是公有构造, 这样做有几大优势:
- 静态工厂方法有名称. 可以更确切地描述正被返回的对象.
当一个类需要多个带有相同签名的构造器时, 可以用静态工厂方法, 并且慎重地选择名称以便突出它们之间的区别. - 不必在每次调用它们的时候都创建一个新对象. 可以重复利用实例. 如果程序经常请求创建相同的对象, 并且创建对象的代价很高, 这项改动可以提升性能. (不可变类, 单例, 枚举).
- 可以返回原类型的子类型对象. 适用于基于接口的框架, 可以隐藏实现类API, 也可以根据参数返回不同的子类型.
由于接口不能有静态方法, 因此按照惯例, 接口Type的静态工厂方法被放在一个名为Types的不可实例化的类中.
(Java的java.util.Collections). 服务提供者框架(Service Provider Framework, 如JDBC)的基础, 从实现中解耦. - 在创建参数化类型实例的时候, 使代码更简洁.
静态工厂方法的缺点:
- 类如果不含public或者protected的构造器, 就不能被子类化. 对于公有的静态工厂方法所返回的非公有类, 也同样如此.
- 静态工厂方法与其他的静态方法没有区别. 在API文档中没有明确标识出来. 可以使用一些惯用的名称来弥补这一劣势:
valueOf(): 类型转换方法, 返回的实例与参数具有相同的值.of(): valueOf()的一种更简洁的替代.getInstance(): 返回的实例通过参数来描述, 对于单例来说, 该方法没有参数, 返回唯一的实例.newInstance(): 像getInstance()一样, 但newInstance()能确保返回的每个实例都与其他实例不同.getType(): 像getInstance()一样, Type表示返回的对象类型, 在工厂方法处于不同的类中的时候使用.newType(): 和newInstance()一样, Type表示返回类型, 在工厂方法处于不同的类中的时候使用.
第2条 遇到多个构造器参数时要考虑用构建器
静态工厂和构造器有一个共同的局限性: 它们都不能很好地扩展到大量的可选参数.
重载多个构造器方法可行, 但是当有许多参数的时候, 代码会很难写难读.
第二种替代方法是JavaBeans模式, 即一个无参数构造来创建对象, 然后调用setter方法来设置每个参数. 这种模式也有严重的缺点, 因为构造过程被分到了几个调用中, 在构造过程中JavaBean可能处于不一致的状态.
类无法通过检验构造器参数的有效性来保证一致性. 另一点是这种模式阻止了把类做成不可变的可能.
第三种方法就是Builder模式. 不直接生成想要的对象, 而是利用必要参数调用构造器(或者静态工厂)得到一个builder对象, 然后在builder对象上调用类似setter的方法, 来设置可选参数, 最后调用无参的build()方法来生成不可变的对象.
这个Builder是它构建的类的静态成员类.
Builder的setter方法返回Builder本身, 可以链式操作.
Builder模式的优势: 可读性增强; 可以有多个可变参数; 易于做参数检查和构造约束检查; 比JavaBeans更加安全; 灵活性: 可以利用单个builder构建多个对象, 可以自动填充某些域, 比如自增序列号.
Builder模式的不足: 为了创建对象必须先创建Builder, 在某些十分注重性能的情况下, 可能就成了问题; Builder模式较冗长, 因此只有参数很多时才使用.
第3条 用私有构造器或者枚举类型强化Singleton属性
Singleton(单例)指仅仅被实例化一次的类. 通常用来代表那些本质上唯一的系统组件.
使类成为Singleton会使得它的客户端代码测试变得困难, 因为无法给它替换模拟实现, 除非它实现了一个充当其类型的接口.
单例的实现: 私有构造方法, 类中保留一个字段实例(static, final), 用public直接公开字段或者用一个public static的getInstance()方法返回该字段.
为了使单例实现序列化(Serializable), 仅仅在声明中加上implements Serializable是不够的, 为了维护并保证单例, 必须声明所有实例域都是transient的, 并提供一个readResolve()方法, 返回单例的实例. 否则每次反序列化一个实例时, 都会创建一个新的实例.
从Java 1.5起, 可以使用枚举来实现单例: 只需要编写一个包含单个元素的枚举类型.
这种方法无偿地提供了序列化机制, 绝对防止多次实例化.
第4条 通过私有构造器强化不可实例化的能力
只包含静态方法和静态域的类名声不太好, 因为有些人会滥用它们来编写过程化的程序. 尽管如此, 它们确实也有特有的用处, 比如:
java.lang.Math, java.util.Arrays把基本类型的值或数组类型上的相关方法组织起来; java.util.Collections把实现特定接口的对象上的静态方法组织起来; 还可以利用这种类把final类上的方法组织起来, 以取代扩展该类的做法.
这种工具类(utility class)不希望被实例化, 然而在缺少显式构造器的情况下, 系统会提供默认构造器, 可能会造成这些类被无意识地实例化.
通过做成抽象类来强制该类不可被实例化, 这是行不通的, 因为可能会造成"这个类是用来被继承的"的误解, 而继承它的子类又可以被实例化.
所以只要让这个类包含一个私有的构造器, 它就不能被实例化了. 进一步地, 可以在这个私有构造器中抛出异常.
这种做法还会导致这个类不能被子类化, 因为子类构造器必须显式或隐式地调用super构造器. 在这种情况下, 子类就没有可访问的超类构造器可调用了.
第5条 避免创建不必要的对象
一般来说, 最好能重用对象而不是每次需要的时候创建一个相同功能的新对象. 如果对象是不可变的(immutable), 它就始终可以被重用.
比如应该用:
String s = "stringette";
而不是:
String s = new String("stringette"); // Don't do this
包含相同字符串的字面常量对象是会被重用的.
对于同时提供了静态工厂方法和构造方法的不可变类, 通常可以使用静态工厂方法而不是构造器, 以避免创建不必要的对象.
比如Boolean.valueOf().
除了重用不可变对象以外, 也可以重用那些已知不会被修改的可变对象. 比如把一个方法中需要用到的不变的数据保存成常量对象(static final), 只在初始化的时候创建一次(用static块), 这样就不用每次调用方法都重复创建.
如果该方法永远不会调用, 那也不需要初始化相关的字段, 可以通过延迟初始化(lazily initializing)把这些对象的初始化放到方法第一次被调用的时候. (但是不建议这样做, 没有性能的显著提高, 并且会使方法看起来复杂.)
前面的例子中, 所讨论的对象显然是能够被重用的, 因为它们被初始化之后不会再改变. 其他有些情形则并不总是这么明显了. (适配器(adapter)模式, Map的接口keySet()方法返回同样的Set实例).
Java 1.5中加入了自动装箱(autoboxing), 会创建对象. 所以程序中优先使用基本类型而不是装箱基本类型, 要当心无意识的自动装箱.
小对象的构造器只做很少量的显式工作, 创建和回收都是很廉价的, 所以通过创建附加的对象提升程序的清晰简洁性也是好事.
通过维护自己的对象池(object pool)来避免创建对象并不是一种好的做法(代码, 内存), 除非池中的对象是非常重量级的. 正确使用的典型: 数据库连接池.
第6条 消除过期的对象引用
一个内存泄露的例子: 一个用数组实现的Stack, 依靠size标记来管理栈的深度, 但是这样从栈中弹出来的过期对象并没有被释放.
称内存泄露为"无意识的对象保持(unintentional object retention)"更为恰当.
修复方法: 一旦对象引用已经过期, 只需清空这些引用即可.
清空对象引用应该是一种例外, 而不是一种规范行为. 消除过期引用最好的方法是让包含该引用的变量结束其生命周期. 如果你是在最紧凑的作用域范围内定义变量, 这种情形就会自然发生.
一般而言, 只要类是自己管理内存, 程序员就应该警惕内存泄露问题. 一旦元素被释放掉, 则该元素中包含的任何对象引用都应该被清空.
内存泄露的另一个常见来源是缓存. 这个问题有这几种可能的解决方案:
- 1.缓存项的生命周期由该键的外部引用决定 ->
WeakHashMap; - 2.缓存项的生命周期是否有意义并不是很容易确定 -> 随着时间的推移或者新增项的时候删除没用的项.
内存泄露的第三个常见来源是监听器和其他回调.
如果你实现了一个API, 客户端注册了回调却没有注销, 就会积聚对象.
API端可以只保存对象的弱引用来确保回调对象生命周期结束后会被垃圾回收.
第7条 避免使用终结方法
终结方法(finalizer)通常是不可预测的, 也是很危险的, 一般情况下是不必要的.
使用终结方法会导致行为不稳定, 降低性能, 以及可移植性问题.
不要把finalizer当成是C++中的析构器(destructors)的对应物.
在Java中, 当一个对象变得不可到达的时候, 垃圾回收器会回收与该对象相关联的存储空间.
C++的析构器也可以用来回收其他的非内存资源, 而在Java中, 一般用try-finally块来完成类似的工作.
终结方法的缺点在于不能保证会被及时地执行. 从一个对象变得不可到达开始, 到它的终结方法被执行, 所花费的时间是任意长的. JVM会延迟执行终结方法.
及时地执行终结方法正是垃圾回收算法的一个主要功能. 这种算法在不同的JVM上不同.
Java语言规范不仅不保证终结方法会被及时地执行, 而且根本就不保证它们会被执行. 所以不应该依赖于终结方法来更新重要的持久状态.
不要被System.gc()和System.runFinalization()这两个方法所迷惑, 它们确实增加了终结方法被执行的机会, 但是它们并不保证终结方法一定会被执行.
如果未捕获的异常在终结过程中被抛出来, 那么这种异常可以被忽略, 而且该对象的终结过程也会终止.
使用终结方法有一个严重的性能损失.
如果类的对象中封装的资源(例如文件或线程)确实需要终止, 应该怎么做才能不用编写终结方法呢? 只需提供一个显式的终止方法. 并要求该类的客户端在每个实例不再有用的时候调用这个方法. 注意, 该实例必须记录下自己是否已经被终止了, 如果被终止之后再被调用, 要抛出异常.
例子: InputStream, OutputStream和java.sql.Connection上的close()方法; java.util.Timer的cancel()方法.
Image.flush()会释放实例相关资源, 但该实例仍处于可用的状态, 如果有必要会重新分配资源.
显式的终止方法通常与try-finally块结合使用, 以确保及时终止.
终结方法的好处, 它有两种合法用途:
- 当显式终止方法被忘记调用时, 终结方法可以充当安全网(safety net). 但是如果终结方法发现资源还未被终止, 应该记录日志警告, 这表示客户端代码中的bug.
- 对象的本地对等体(native peer), 垃圾回收器不会知道它, 当它的Java对等体被回收的时候, 它不会被回收. 如果本地对等体拥有必须被及时终止的资源, 那么该类就应该有一个显式的终止方法, 如前, 可以是本地方法或者它也可以调用本地方法; 如果本地对等体并不拥有关键资源, 终结方法是执行这项任务最合适的工具.
注意, 终结方法链(finalizer chaining)并不会自动执行. 子类覆盖终结方法时, 必须手动调用超类的终结方法. try中终结子类, finally中终结超类.
为了避免忘记调用超类的终结方法, 还有一种写法, 是在子类中写一个匿名的类, 该匿名类的单个实例被称为终结方法守卫者(finalizer guardian), 当守卫者被终结的时候, 它执行外围实例的终结行为. 这样外围类并没有覆盖超类的终结方法, 保证了超类的终结方法一定会被执行.
