设计模式之一单例模式

* 使用场景：项目中有一个计算借款人向我平台收取相关费用的需求，计算这个费用呢，会多次使用到，而且费率是平台根据政策有可能变更其中的某些费率数据。因此，我当时就想着把，平台设定的费率数据放在配置文件中，然后从配置文件中读取参数来计算平台应该收取的费用。比如，配置文件是config-test.properties，假如我们用一个不同类FeeConfig来读取配置文件，很容易就能读取到，但是这里有一个问题。因为会有好多地方需要计算费用，因此，每一个需要使用到的地方，都要去创建一个FeeConfig对象。换句话说，系统在运行期间，将会存在多个FeeConfig的实例，而每一个实例中都存在着config-test.properties中的内容，如果配置文件内容比较多时候，就会造成系统资源的浪费。


* 单例模式定义：这个从字面的意思来看，就是某一个类只能够有一个类实例。也就是说不能通过构造函数来new出很多对象来。
* 单例模式如何解决问题：


1. 首先，如果我们给一个类只能创建一个实例，这样是不是就可以解决上面个的问题。可是只要我们对外提供了构造器，就无法控制一个类只能创建一个实例。所以，我们的类内部自己创建实例，将构造器私有化，只对外界提供一个访问实例的接口就行了。
2. 然后，问题来了，我们什么时候为这个类自己创建一个实例呢？这就出现了饿汉式和懒汉式的单例模式设计。我有时候也分不清，但可以这么理解，饿汉式就是饿了立即就想要，所以在单例模式中，直接创建实例。而懒汉式，就是在需要的生活我们才创建，也就是说在提供接口供外界访问的时候，再决定还要不要创建实例。


* 单例模式代码讲解：

懒汉式：
package com.wang.demo;

public class FullSingleTon {
/**
* 构造器私有化
*/
private FullSingleTon(){

 }
 /**
  * 存储类的实例
  */
 private static FullSingleTon fullMan = null;
 /**
  * 提供公共接口供外界访问
  * @return
  */
 public static FullSingleTon getInstance(){
        if( fullMan == null){
             //如果还没有实例化，此时实例化
             fullMan = new FullSingleTon();
       }
        return fullMan;
 }

}

饿汉式：
package com.wang.demo;
/**
* 饿汉式单例模式
* @author xiaoezi
*
*/
public class HungreSingleTon {

 /**构造器私有，只能本方法中使用**/
 private HungreSingleTon(){

 }

 /**
  * 定义一个变量存储创建好的类实例
  */
 private static HungreSingleTon hungreMan = new HungreSingleTon();

 /**
  * 提供公共接口供外界调用
  */
 public static HungreSingleTon getInstance(){
        return hungreMan;
 }

}

这里我们来讲解一下：

1. 构造器私有，只能这个类内部访问，所以外界无法通过构造器来创建该类的实例化对象。
2. 既然外界不能实例化，那么必须提供一个接口给外界让外界想要使用的去读取该类内部提供的唯一一个实例化对象。所以必须是public的，但是外加无法通过new一个对象来调取这个获取实例的方法，所以必须是static的。
3. 由于获取实例的方法是static的，因此我们在创建类实例的时候也必须是static的。


* 单例模式的优缺点


1. 时间和空间：懒汉式是以时间换取空间，有延迟加载的思想。也就是说，每次获取实例的时候都去判断是否需要创建实例，花了一定的时间。如果没有人使用的时候，一直都不会去创建对象，节省了空间。而饿汉式恰恰相反，是以空间换取时间。当类加载的生活立即创建类实例。每次调用的时候就不需要创建了，节省了时间。
2. 线程安全：懒汉式是不安全的，比如有两个线程A，B，他们同时调用getInstance（）方法，那就可能导致并发问题。

然后程序继续运行，两个线程都向前走一步：

此时，问题就来了，这个控制并不起作用，会产生并发问题。下面我们会讨论如何解决这个问题。
饿汉式是线程安全的，因为虚拟机保证只会装载一次，装载类的时候是不会发生并发的。

* 解决懒汉式的并发问题

解决并发问题之前，我们介绍一个关键字：synchronized。《java编程思想》是这样描述的：java已提供关键字synchronized的形式，为防止资源冲突提供了内置支持，当任务要执行被synchronized修饰的代码片段的时候，她将检查锁是否可用，然后获取锁，执行代码，释放锁。所以我们的第一个思路就是getInstantce()方法加上这个关键字，不管谁访问的时候都先去检查锁是否可用，可用就获取锁，不可用就等待别人释放锁。
那么修改如下：
public static synchronized FullSingleTon getInstance(){
if( fullMan == null){
//如果还没有实例化，此时实例化
fullMan = new FullSingleTon();
}
return fullMan;
}
但是这样一来，又会降低整个访问的速度，因为你每次调用这个方法首先要判断锁是否可用，还需要判断是否实例化对象。这里可以使用双重检查枷锁来实现，既线程安全又能使性能不受到很大的影响。
所谓的双重加锁机制：代码如下：
public static FullSingleTon getInstance(){
//先检查类实例是不是存在，如果不存在才执行同步块
if( fullMan == null){
synchronized(FullSingleTon. class){
//再次检查类实例是否存在，如果不存在才创建类实例
if( fullMan == null){
fullMan = new FullSingleTon();
}
}
}
return fullMan;
}