第2章 建立和销毁对象

本章的主题是建立和销毁对象:什么时候以及如何建立对象,什么时候以及如何避免建立对象,如何确保它们可以适时地销毁,以及如何管理对象销毁以前必须进行的各类清理动做。 ###第1条:考虑用静态工厂方法代替构造器###   获取类的实例有两个方法,类提供一个公有的构造器和提供一个公有的只返回类的实例静态工厂方法(static factory method)。
  例如将boolean基本类型值转换成一个Boolean对象引用:java

public static Boolean valueOf(boolean b)
{
    return b ? Boolean.TRUE : Boolean.FALSE;
}

  这里的静态工厂方法与设计模式中的工厂方法模式不一样。
  静态工厂方法比公有的构造器有几大优点:
1.它们有名称
  若是构造器的参数自己没有确切的描述正被返回的对象那么具备适当名称的静态工厂方法会更容易使用。例如构造器BigInteger(int, int, Random)返回的BigInteger可能为素数,若是用名为BigInteger.probablePrime的静态工厂方法表示显然更清楚。
2.没必要在每次调用它们的时候都建立一个新对象
  这使得不可变类可使用预先构建好的实例,或者将构建好的实例缓存起来进行重复利用,从而避免建立没必要要的重复对象。
  静态工厂方法可以为重复的调用返回相同对象,这样有助于类总能严格控制在某个时刻哪些实例应该存在。这种类被称做实例受控的类(instance-controlled),实例受控使得类能够确保它是一个Singleton或者是不可实例化的。它还使得不可变的类能够确保不会存在两个相等的实例,即当且仅当a==b的时候才有a.equals(b)为true。若是能够保证这一点就可使用==代替equals()方法,这样能够提高性能,枚举(enum)保证了这一点。
3.它们能够返回原返回类型的任何子类型对象
  公有的静态工厂方法所返回的对象的类不只能够是非公有的,并且该类还能够随着每次调用而发生变化,这取决于静态工厂方法的参数值。只要是已声明的返回类型的子类型,都是容许的。
  例如java.util.enumSet没有公有构造器,只有静态工厂方法程序员

/**
     * Creates an empty enum set with the specified element type.
     *
     * @param elementType the class object of the element type for this enum
     *     set
     * @throws NullPointerException if <tt>elementType</tt> is null
     */
    public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
        Enum[] universe = getUniverse(elementType);
        if (universe == null)
            throw new ClassCastException(elementType + " not an enum");

        if (universe.length <= 64)
            return new RegularEnumSet<>(elementType, universe);
        else
            return new JumboEnumSet<>(elementType, universe);
    }

  它返回两种实现类之一,具体则取决于底层枚举类型的大小:若是它的元素有64个或者更小会返回一个RegularEnumSet实例不然返回JumboEnumSet实例。
  静态工厂方法返回的对象所属的类在编写该静态工厂方法的类的时候能够没必要存在,这种灵活的静态工厂方法构成了服务提供者框架(Service Provider Framework)(多个服务提供者实现一个服务,系统为服务提供者的客户端提供多个实现,并把他们从多个实现中解耦出来)的基础。
  服务提供者框架中有三个重要的组件:服务接口(Service Interface),这是提供者实现的;提供者注册API(Provider Registration API),这是系统用来注册实现让客户端访问他们的;服务访问API(Service Access API),是客户端用来获取服务的实例的。第四个组件是可选的:服务提供者接口(Service Provider Interface),这些提供者负责建立其服务实现的实例。若是没有服务提供者接口,实现就按照类名称注册,并经过反射方式进行实例化。
  对于JDBC来讲,Connection就是它的服务接口,DriverManager.registerDriver是提供者注册API,DriverManager.getConnection是服务访问API,Driver就是服务提供者接口。
  客户端调用的方式sql

Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);

  Connection是一个接口提供了操做数据库的各类方法:数据库

public interface Connection extends Wrapper, AutoCloseable {
	public abstract Statement createStatement() throws SQLException;
	public abstract PreparedStatement prepareStatement(String s) throws SQLException;
	public abstract CallableStatement prepareCall(String s) throws SQLException;
	... ...
}

  DriverManager的registerDriver方法以下:设计模式

public static synchronized void registerDriver(Driver driver) throws SQLException
{
    if(driver != null)
        registeredDrivers.addIfAbsent(new DriverInfo(driver));
    else
        throw new NullPointerException();
    println((new StringBuilder()).append("registerDriver: ").append(driver).toString());
}

  Driver是一个接口:数组

public interface Driver 
{
	public abstract Connection connect(String s, Properties properties) throws SQLException;
	public abstract boolean acceptsURL(String s) throws SQLException;
	public abstract DriverPropertyInfo[] getPropertyInfo(String s, Properties properties) throws SQLException;
	public abstract int getMajorVersion();
	public abstract int getMinorVersion();
	public abstract boolean jdbcCompliant();
	public abstract Logger getParentLogger() throws SQLFeatureNotSupportedException;
}

  其中DriverManager.getConnection(String s, String s1, String s2)经过下面代码得到Connection缓存

Connection connection = driverinfo.driver.connect(s, properties);

  服务提供者框架模式有着无数种变体,例如服务访问API能够利用适配器(Adapter)模式返回比提供者须要的更丰富的服务接口。下面是一个简单实现:安全

// 服务接口
public interface Service
{
	...//服务操做的方法
}

// 服务提供者接口
public interface Provider
{
	Service newService();// 返回具体的服务实例
}

// 用于注册和访问服务的不可实例化的类
public class Services 
{
	// 构造函数声明为私有的不可实例化
	private Services()
	{
	}
	
	// 存储服务名字和对应的服务
	private static final Map<String, Provider> providers = new ConcurrentHashMap<String, Provider>();
	public static final String DEFAULT_PROVIDER_NAME = "<def>";
	
	// 提供注册接口
	public static void registerProvider(String name, Provider p)
	{
		providers.put(name, p);
	}
	
	// 服务访问接口
	public static Service newInstance()
	{
		return newInstance(DEFAULT_PROVIDER_NAME);
	}
	public static Service newInstance(String name)
	{
		Provider p = providers.get(name);
		if(p == null)
		{
			throw new IllegalArgumentException("No provider registered with name: " + name);
		}
		
		return p.newService();
	}
}

4.在建立参数化类型实例的时候它使代码更简洁   在调用参数化类的构造器的时候一般要求提供两次类型参数,若是参数不少会比较冗长。经过静态工厂方法,编译器能够找到类型参数,这被称做类型推倒(type inference),例如:app

Map<String, List<String>> m = New HashMap<String, List<String>>();

  假设HashMap提供了这个静态工厂:框架

public static <K, V> HashMap<K, V> newInstance()
{
	return new HashMap<K, V>();
}
Map<String, List<String>> m = HashMap.newInstance();

  静态工厂方法也有缺点:
1.类若是不含有public或protected的构造器就不能被子类化。
  可是也能够塞翁失马,由于鼓励使用复合(composition)而不是继承。
2.它们与其余的静态方法实际上没有任何区别从而不容易知道如何实例化一个类。 ###第2条:遇到多个构造器参数时要考虑使用构建器###   静态工厂和构造器都不能很好的扩展到大量的可选参数,若是可选参数多的话一般有两种方式建立类的实例。
1.重载构造器
  须要写太多个构造器并且客户端的代码也会很难编写
2.使用JavaBeans模式
  调用一个无参的构造器建立对象而后调用setter方法来设置每一个必要的参数以及相关的可选参数,这种方式弥补了重载构造器模式的不足代码读起来也容易。可是也有一些缺点,在构造过程当中JavaBean可能处于不一致的状态,类没法仅仅经过检验构造器参数的有效性来保证一致性。例如new了一个类的两个实例,一个只set了A属性,一个只设置了B属性,这两个实例不一致,不能保证经过该类的同一个构造器构造出来的对象是属性相同的。另外,这样类就不是不可变类(不可变对象指对象一旦被建立,状态就不能再改变。任何修改都会建立一个新的对象,如 String、Integer及其它包装类)了,就须要付出额外的努力来确保它的线程安全。
3.Builder模式既能保证像重叠构造器模式那样的安全性也能保证像JavaBeans模式那么好的可读性。
  例如:

public class TestBuilder 
{
	public static void main(String[] args) 
	{
		Student student = new Student.Builder("victor", 1).age(25).address("上海").Builder();
	}
}

/**
 * @author victor
 * 学生类。姓名和性别是必填参数,年龄和住址是可选的
 */
class Student 
{
	private String name;
	private int gender;
	private int age;
	private String address;
	
	public static class Builder
	{
		private String name;
		private int gender;
		// 初始化可选参数
		private int age = 12;
		private String address = "北京";
		
		public Builder(String name, int gender)
		{
			this.name = name;
			this.gender = gender;
		}
		
		public Builder age(int age)
		{
			this.age = age;
			return this;
		}
		public Builder address(String address)
		{
			this.address = address;
			return this;
		}
		
		public Student Builder()
		{
			return new Student(this);
		}
	}
	
	private Student(Builder builder)
	{
		this.name = builder.name;
		this.gender = builder.gender;
		this.age = builder.age;
		this.address = builder.address;
	}
}

  若是类的构造器或者静态工厂中具备多个参数能够思考一下是否用Builder模式更适合。 ###第3条:用私有构造器或者枚举类型强化Singleton属性###   Singleton指仅仅被实例化一次的类。
  在Java 1.5以前实现Singleton有两种方法,这两种方法都要把构造器保持为私有的并导出公有的静态成员。
  第一种方法:

public class Singleton 
{
	public static final Singleton INSTANCE = new Singleton();
	
	private Singleton()
	{
		
	}
}

  私有构造器仅被调用一次,用来实例化公有的静态final域,保证了Singleton的全局惟一性。可是享有特权的客户端能够经过反射机制调用私有构造器,若是须要抵御这种攻击,能够修改构造器在建立第二个实例的时候抛出异常。
  第二种方法:
  公有的成员是个静态工厂方法

public class Singleton 
{
	private static final Singleton INSTANCE = new Singleton();
	
	private Singleton()
	{
		
	}
	
	public static Singleton getInstance()
	{
		return INSTANCE;
	}
}

  第一种公有域的方法主要好处在于组成类的成员的声明很清楚的代表了这个类是一个Singleton:公有的静态域是final的,因此该域老是包含相同的对象引用。公有域方法在性能上再也不有任何优点:现代的JVM实现几乎都可以将静态工厂方法的调用内联化。
  第二种工厂方法的优点之一在于,它提供了灵活性:在不改变其API的前提下,咱们能够改变该类是否应该为Singleton的想法。第二个优点与泛型有关。
  使用其中一种方法实现的Singleton类变成可序列化(Serializable)仅仅在声明中加上"implement Serializable"是不够的。为了维护并保证Singleton,必须声明全部实例域都是瞬时(transient)的,并提供一个readResolve方法。不然,每次反序列化一个序列化的实例时都会建立一个新的实例。
  从Java 1.5版本起实现Singleton还有第三种方法。只需编写一个包含单个元素的枚举类型:

public enum People 
{
	INSTANCE;
	public void speak()
	{
		System.out.println(this + " is speaking! ");
	}
}
public class Singleton 
{
	public static void main(String[] args)
	{
		People s1 = People.INSTANCE;
	    s1.speak();
	    People s2 = People.INSTANCE;
	    s2.speak();
	    System.out.println(s1 == s2);
	}
}

  运行结果:

INSTANCE is speaking! 
INSTANCE is speaking! 
true

  这种方法在功能上与公有域方法相近,可是更加简洁而且无偿的提供了序列化机制,绝对防止屡次实例化,即便是在面对复杂的序列化或者反射攻击的时候。单元素的枚举类型已经成为实现Singleton的最佳方法。 ###第4条:经过私有构造器强化不可实例化的能力###   有一些工具类不但愿被实例化,实例对它没有任何意义。因为只有当类不包含显示的构造器时,编译器才会生成缺省的构造器,所以只要让这个类包含私有构造器就不能被实例化了。

public class UtilityClass 
{
	// Suppress default constructor for non-instantiability
	private UtilityClass()
	{
		throw new AssertionError();
	}
}

  反作用就是使得该类不能被子类化,由于全部的构造器都必须显示或隐式的调用超类构造器,在这种情形下,子类就没有可访问的超类构造器可调用了。 ###第5条:避免建立没必要要的对象###   通常来讲,最好能重用对象而不是在每次须要的时候就建立一个相同功能的新对象。重用方式既快速,又流行。若是对象是不可变(immutable)的它始终能够被重用。
  一个极端的例子:String s = new String("stringette");
  "stringette"自己就是一个String实例,功能方面等同于构造器建立的全部对象。
改进后的版本:String s = "stringette";能够保证对于全部在同一台虚拟机中运行的代码,只要它们包含相同的字符串字面常量该对象就会被重用。
  对于同时提供了静态工厂方法和构造器的不可变类,一般可使用静态工厂方法而不是构造器以免建立没必要要的对象。例如,静态工厂方法Boolean.valueOf(String)老是优于构造器Boolean(String)。构造器在每次被调用的时候都会建立一个新的对象,而静态工厂方法则历来不要求这样作。
  除了重用不可变的对象以外也能够重用那些已知不会被修改的可变对象,下面是一个常见的反例,检验一我的是否出生于1946年至1964年期间:

public class Person 
{
	private final Date birthDate = null;
	
	public boolean isBabyBoomer()
	{
		Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
		gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
		Date boomStart = gmtCal.getTime();
		gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
		Date boomEnd = gmtCal.getTime();
		return birthDate.compareTo(boomStart) >= 0 && birthDate.compareTo(boomEnd) < 0;
	}
}

  isBabyBoomer每次被调用的时候都会新建一个Calendar、一个TimeZone和两个Date实例,这是没必要要的。改进后代码的以下:

public class Person 
{
	private final Date birthDate = null;
	private static final Date BOOM_START;
	private static final Date BOOM_END;
	
	static
	{
		Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
		gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
		BOOM_START = gmtCal.getTime();
		gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
		BOOM_END = gmtCal.getTime();
	}
	
	public boolean isBabyBoomer()
	{
		return birthDate.compareTo(BOOM_START) >= 0 && birthDate.compareTo(BOOM_END) < 0;
	}
}

  在Java1.5以后有一种建立多余对象的新方法称做自动装箱(autoboxing),它容许程序员将基本类型和装箱基本类型混用,按须要自动装箱和拆箱。
  例如以下程序计算全部int正值的总和:

public static void main(String[] args)
{
		Long sum = 0L;
		for(long i = 0; i < Integer.MAX_VALUE; i++)
		{
			sum += i;
		}
		System.out.println(sum);
}

  sum声明为Long而不是long程序就会构造大约2^31个多余的Long实例。
  优先使用基本类型而不是装箱基本类型,要小心无心识的自动装箱。
###第6条:消除过时的对象引用###   虽然Java具备自动垃圾回收机制,可是也须要考虑内存管理的事情。
  例如以下代码:

public class Stack 
{
	private Object[] elements;
	private int size = 0;
	private static final int DEFAULT_INITIAL_CAPACITY = 16;
	
	public Stack()
	{
		elements = new Object[DEFAULT_INITIAL_CAPACITY];
	}
	
	public void push(Object e)
	{
		ensureCapacity();
		elements[size++] = e;
	}
	
	public Object pop()
	{
		if(size == 0)
		{
			throw new EmptyStackException();
		}
		
		return elements[--size];
	}
	
	private void ensureCapacity()
	{
		if(elements.length == size)
		{
			elements = Arrays.copyOf(elements, 2*size + 1);
		}
	}
}

  这是一个栈先增加而后再收缩,可是从栈中弹出来的对象将不会被看成垃圾回收,即便使用栈的程序再也不引用这些对象。这是由于栈内部维护着对这些对象的过时引用,所谓的过时引用是指永远也不会再被解除的引用。在上述程序中凡是在数组活动部分以外的任何引用都是过时的,活动部分是指elements中下标小鱼size的那些元素。
  pop方法的修复版本以下:

public Object pop()
{
	if(size == 0)
	{
		throw new EmptyStackException();
	}
		
	Object result = elements[--size];
	elements[size] = null;
	return result;
}

  只要类是本身管理内存,就应该警戒内存泄露的问题。 ###第7条:避免使用终结方法###   终结方法(finalizer)一般是不可预测的也是很危险的,通常状况下是不可预测的。   终结方法的缺点在于不能保证会被及时地执行,从一个对象变得不可到达开始,到它的终结方法被执行所花费的这段时间是任意长的。Java语言规范不只不保证终结方法会被即便地执行并且根本就不保证它们会被执行。   不该该依赖终结方法来更新重要的持久状态。例如,依赖终结方法来释放共享资源(例如数据库)上的永久锁很容易让整个分布式系统垮掉。   另外,若是在终结方法之中发生了异常则该异常不会使线程终止也不能打印出栈轨迹,不利于问题定位分析。   始终终结方法有一个很是严重的性能损失,用终结方法建立和销毁对象很是慢。   若是类的对象中封装的资源(例如文件或者线程)确实须要终止只需提供一个显示的终止方法,例如InputStream、OutputStream和java.sql.Connection上的close方法以及java.util.Timer上的cancel方法。显示的终止方法一般与try-finally结构结合起来使用,以保证及时执行。

相关文章
相关标签/搜索