对象的创建和销毁
第一条 用静态工厂方法来代替构造器
类除了可以通过构造器来实例化之外，还可以通过静态的工厂方法（newInstance）
优势
1. 他们有名称
比如一个Apple类，你想获得一个红苹果和绿苹果的实例，Apple.newRedInstance()和Apple.newGreenInstance()比Apple(red)和Apple(green)看上去要更能突出他们之间的区别
2. 不必在每次调用的时候都创建一个新对象
class Apple{
private Apple apple;
private Apple();
newInstance(){
return apple ==null ?new Apple : apple;
}
}
单例模式的简单写法，单例模式的有各种好处，比如不用重复创建对象，可以用==来代替equals方法等等之类的我就不多说神马了。
3. 可以返回原返回类型的任何子类型对象
这种时候我们在返回对象的类时就有了更大的灵活性，甚至于我们在编写该静态方法的时候这个类是可以不存在的。书上管这个叫服务提供者框架(Service Provicer Framework)。 例如JDBC 的API就是一个很好的例子。Connection是他的服务接口，DriverManager.registerDriver 是提供者的API，DriverManager.getConnection是服务访问的API，Driver就是服务提供者接口。适配器模式也是这种框架的一种变体。
// 服务提供者框架简易Demo
// 服务类的接口
public interface Service{
// 具体需要实现的服务方法
}
// 服务提供者的接口
public interface Provider{
Service newService();
}
// Service 注册和调用的类
public class Services{
private Services(); // 防止实例化
// Service 名字跟服务的Map
private static final Map providers = new ConcurrentHashMap( );
public static final String DEFAULT_PROVIDER_NAME = "";
// 服务提供者注册的API
public static void registerDefaultProvider(Provider p){
registerProvider(DEFAULT_PROVIDER_NAME ,p);
}
public static void registerDefaultProvider(String name ,Provider p){
providers.put(name ,p);
}
// 获取服务接口
public static Service newInstance(){
return newInstance(DEFAULT_PROVIDER_NAME);
}
publicstatic Service newInstance(String name ){
Provider p = providers.get(name);
if(p== null)
throw new IllegalArgumentException("这个服务者没有注册");
return p.newService();
}
适配器模式的简单例子。
4. 实例化参数类型时更简单
比如
Map> m = new HashMap>();
随着参数越来越长，越来越复杂，代码就越来越丑了。
这个时候如果有这个方法
public static HashMap newInstance(){
return new HashMap();
}
那我们只要这样写就好了Map,代码就简洁了好多。目前（jdk 1.8.0_73）官方并没有实现这样的方法，可以放在自己的工具类中体现自己的逼格。
缺点
- 如果类不含public 或者protect 的构造方法则不能被实例化
是缺点也是优点，关键看你肿么用吧。。。 - 不能在java doc中有什么体现。
java doc认识构造方法，会重点标识出来，但是静态方法不会，所以用起来找api会麻烦。
第二条 当构造方法有多个可选参数的时候考虑用构造器
当实例化一个类有很多可选参数的时候，有如下的几种方法
创建多个构造器
优点： 能用
缺点：写起来容易错，参数的顺序啊神马的记起来容易错
用JavaBean 的getter 和setter 模式
优点：写的时候不容易出错
缺点：线程不安全
使用构造器模式
优点：使代码简单好些，而且看上去很有逼格
缺点：增加了一些开销
拿一个苹果类举例
class Apple{
private String color;
private String size;
private String weight;
private String price;
public static class Builder{
private String color;
private String size;
private String weight;
public Builder color(String color){
this.color = color;
return this;
}
public Builder size(String size){
this.size = size;
return this;
}
public Builder weight(String weight){
this.weight = weight;
return this;
}
public Apple bulid(){
return new Apple(this);
}
}
private Apple(Builder bulider){
this.color = bulider.color;
this.size = bulider.size;
this.weight = bulider.weight;
};
}
然后就可以通过下面的方式来实例化一个苹果
Apple apple = new Apple.Builder().color("red").size("100").weight("100").bulid();
这样逼格满满的代码就出来了。在可选参数很多的时候选择这种写法是种很不错的选择。
第三条 单例的三种写法和注意事项
原翻译 使用枚举增强类的单例属性
单例模式的各种好处就不说，这条讲了单例的三种写法和注意事项
写法一
class Apple{
public static Apple INSTANCE = new Apple();
// someThing
private Apple(){
};
}
写法二
class Apple{
private static Apple INSTANCE = new Apple();
// someThing
private Apple(){
};
public static Apple newInstance(){
return INSTANCE;
}
}
*** 注意事项 ***
AccessibleObject.setAccessible可以通过反射调用私有的构造方法。在构造器加上第二次实例化抛异常的逻辑可以防范这种攻击。如果单例的类为了可序列化而继承了
Serializable接口，那么为了防止类在反序列化的时候被偷偷的实例化，可以在类中加入如下代码
private Object readResolve() {
return INSTANCE;
}
写法三 使用枚举实现单例
enum Apple{
INSTANCE;
}
- 优点
简单明了，不仅能防止因为反序列而重新创建对象，又是线程安全的，简直逼格满满 - 缺点
这是JDK1.5之后的新特性，这么写可能有些人会看不懂（怪我咯j╮(╯_╰)╭）。
第4条 通过私有化构造器使单例类更加单例
有些工具类我们可能不希望它被实例化，可以使用如下代码
public class AppleUtils{
private AppleUtils(){
throw new AssertionError();
}
}
这样一来，AppleUtils（和他的子类）就不能被实例化了。
第5条 避免创建不必要的对象
对象么能少创建就少创建，这条主要讲了如何更少的创建对象
- 比如不要写
String s = new String("Don't do this");这样的代码(因为这里创建了两个String 对象) - 对于有静态工厂方法和构造器的不可变类，尽量使用静态工厂方法
- 对象能重用的就尽量重用
明显能重用那肯定是要重用的，有些不明显的比如像Map接口的KeySet方法每次返回的Set实例这种也是考虑用一个对象减少实例化的 - 使用基本数据类型时防止程序自从装箱
例如如下代码
Long sum =0L;
for (int i = 0; i < Integer.MAX_VALUE; i++) {
sum +=i;
}
System.out.println(sum);
这段代码在我机器上的运行时间为
但是如果把Long sum 换成long sum
可以看到时间从6886ms变成了781ms,效率大大的优化了。
第六条 避免内存泄露的几点建议
原翻译:消除过期的对象引用
- 警惕自己管理内存的类
- 警惕让不用的对象留在缓存中
wakHashMap 和LinkedHashMap 可以一定程度解决这个问题 - 警惕监听器和其他回调
最好只保存他们的若引用，例如只将他们保存成WeakHashMap中的键
第七条 避免使用终结（finalizer）方法
- finalizer方法并不能保证被及时的执行
从对象不可到达到它的finalizer方法被执行，其中的这段时间是不好估计的。 - finalizer方法并不能保证被正确的执行
不同的JVM实现中finalizer的效果是不同的。 - finalizer方法并不能保证被执行
当一个程序被终止的时候，某些已经无法访问的对象上的终结方法没有被执行也是有可能的。 - finalizer 有一个非常严重的性能损失
Effective Java的作者说他试了下，真的有很严重的性能损失。
所以最好有显示的终止方法，向InputStream、OutputStream``的close方法，java.util.Timer中的cancel```方法之类的。
总结
这一章主要讲了对象的创建和销毁时候需要注意的一些点。有些代码真的是使人豁然开朗，瞬间逼格满满。期待第二章的学习，Fighting~