单例模式(Singleton Pattern) 是指确保一个类在任何情况下都绝对只有一个实例,并提供一个全局的访问点。比方说，你只能有一个女朋友,你是new不出来的.
前言写文章的目的主要是为了自己知识的巩固,当然也十分希望在此能够得到业界前辈们的指导。
本文主要围绕:懒汉单例、饿汉单例、枚举单例、容器单例。以及会分析他们为什么会是线程安全和不安全。
一、饿汉单例该单例模式咱们直接看代码,因为比较简单。
public class HungrySingleton {
//声明一个实例 final修饰
private static final HungrySingleton hungrySingleton = new HungrySingleton();
//私有化构造函数
private HungrySingleton(){}
//提供访问点
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
public class HungrySingleton {
private static final HungrySingleton hungrySingleton ;
static {
hungrySingleton = new HungrySingleton();
}
private HungrySingleton(){}
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
以上两种方法并没有特别之处,看个人喜欢选择. 饿汉单例: 1.私有化构造函数 2.对外提供一个访问点.
优点： 1.属性线程安全的(为什么是线程安全的?) 2.没有加任何的锁、执行效率比较高， 缺点： 浪费内存空间(因为只要类被加载就会创建一个实例。)
解释一下为什么是线程安全的,其实很容易理解,私有化了构造函数,无法主动创建实例,该类在被加载的时候创建了一个实例。也就是说在线程还没出现就已经实例化了，所以不存在线程安全问题。 对于饿汉单例的缺点,懒汉模式解决它的缺点。
二、懒汉单例懒汉式单例,在第一次调用的时候实例化本身。
public class LazySimpleSingleton {
private static LazySimpleSingleton lazy = null;
private LazySimpleSingleton (){};
//此处可以看做是一个简单的工厂方法.
public static LazySimpleSingleton getInstance(){
if(lazy == null){
//此处有可能会出现两个实例，所以是线程不安全的
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
懒汉式单例的设计,确实是在一定程度上解决了饿汉单例带来的内存浪费问题，但是也因此暴露了新的问题，那就是线程安全问题。下面请看,模拟两个线程
public class LazySimpleSingletonTest implements Runnable{
@Override
public void run() {
LazySimpleSingleton simpleSingleton = LazySimpleSingleton.getInstance();
System.out.println(Thread.currentThread().getName()+":"+simpleSingleton);
}
}
public static void main(String[] args) {
Thread t1 = new Thread(new LazySimpleSingletonTest());
Thread t2 = new Thread(new LazySimpleSingletonTest());
t1.start();
t2.start();
}
Thread-0:com.gp.singleton.lazy.LazySimpleSingleton@5ee86afd
Thread-1:com.gp.singleton.lazy.LazySimpleSingleton@6f8ef171
此处就出现了线程安全问题,线程本身就是存在概率的你可以多测几次。 那么会什么会出现这个问题呢？
我
们
来
进
行
断
点
测
试
(
使
用
线
程
d
e
b
u
g
)
\color{#FF0000}{我们来进行断点测试(使用线程debug)}
我们来进行断点测试(使用线程debug) 在以下两处打个断点,右键断点选择Thread可以选择线程模式。 
当第一个线程进入到if方法中的时候切换线程(从Thrad0切换到Thrad1,目的为了让两个线程同时处在if方法中)
注
意
T
h
r
a
d
0
还
没
有
赋
值
\color{#FF0000}{注意Thrad0还没有赋值}
注意Thrad0还没有赋值 
当Thread1进入到if方法中的时候可以先让Thread1执行完，在切换Thread0执行完毕！ 我们来看下结果. 
你就会发现此处就出现了两个实例了.破坏了单例的原则。因为线程本来就是抢时间执行的，当A线程执行到if中被B线程夺走了执行权，那么只要当他们同时进入到if中那么就都会new个各自的实例出来。
给方法加上synchronized关键字
public synchronized static LazySimpleSingleton getInstance(){
if(lazy == null){
//此处有可能会出现两个实例，所以是线程不安全的
lazy = new LazySimpleSingleton();
}
return lazy;
}
synchronized 的作用是可以让此方法变成线程同步的方法。如果这个时候当我们将其中一个线程执行并调用getInstance()方法时，另一个线程在调用 getInstance()方法，线程的状态由RUNNING 变成了MONITOR,出现阻塞。直到第一个线程执行完，第二个线程才恢复RUNNING状态继续调用getInstance()方法。 这里就不给大家演示了。 注 意 s y n c h r o n i z e d \color{#FF0000}{注意synchronized} 注意synchronized使用此方法能够解决线程安全问题，虽然JDK1.6之后就对synchronized性能做了优化，但是还是会不可避免的造成一些新的问题。 例如：当线程数较多的情况下使用 s y n c h r o n i z e d \color{#FF0000}{synchronized} synchronized加锁，会出现类锁 ，导致大批线程阻塞，从而导致性能大幅度下降。那么有没有解决办法呢？使用 双 重 检 查 锁 \color{#FF0000}{双重检查锁} 双重检查锁
解决方法2：双重检查锁 我们修改一下getInstance()方法
public static LazySimpleSingleton getInstance(){
if(lazy == null){
synchronized (LazySimpleSingleton .class ){
if(lazy == null){
lazy = new LazySimpleSingleton ();
}
}
}
return lazy;
}
解释一下：当第一个线程调用getInstance()方法时，第二个线程也可以调用getInstance()。当第一 个线程执行到synchronized时会上锁，第二个线程就会变成MONITOR 状态，出现阻塞。此时，阻塞并不是基于整个LazySimpleSingleton类的阻塞，而是在getInstance()方法内部阻塞。在逻辑不是很复杂的条件下对于调用者是不会察觉到的。 但是使用 s y n c h r o n i z e d \color{#FF0000}{synchronized} synchronized关键字就会在一定程度上降低性能，因为不管怎么样总会上锁。优化：使用静态内部类
解决方法3静态内部类 此方法也能实现线程安全，性能最优 优点： 1.没有synchronized关键字，提高了性能 2.内部类会先加载。当外部方法调用了getInstance时才会返回一个实例. 这种形式兼顾饿汉式的内存浪费，也兼顾synchronized性能问题，为什么这么说呢？ 因为内部类会比外部类先加载，而我们只有使用了外部类内部类才会被加载。
public class LazyInnerClassSingleton {
private LazyInnerClassSingleton (){};
//此次相当于懒汉单例
public static final LazyInnerClassSingleton getInstance(){
return LazyHolder.LAZY;
}
//此次相当于饿汉式单例
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
此方法虽然性能最优，但是你会发现构造器只是被私有化了，并没有做任何处理。那么会存在什么问题呢？ 反射攻击
问题1.反射攻击 public static void main(String[] args) {
try {
Class cls = LazyInnerClassSingleton.class;
Constructor constructor = cls.getDeclaredConstructor(null);
constructor.setAccessible(true); //得到私有访问权限
Object o1 = constructor.newInstance();
Object o2 = LazyInnerClassSingleton.getInstance();
System.out.println( o1 == o2); //o1 == o2 false
} catch (Exception e) {
e.printStackTrace();
}
}
你会发现通过反射得到的对象与getInstance()方法返回的对象时不相等的。此处调用了两次构造方法，相当于new了两次。如何解决？在构造方法中添加判断?
解决1：反射攻击修改内部类中的构造方法。
private LazyInnerClassSingleton (){
//此处加个判断能放止反射攻击
if(LazyHolder.LAZY != null){
throw new RuntimeException("非法创建实例!");
}
};
我们来看看现在继续使用反射返回的结果----> 
直接抛出了RuntimeException，这样就解决了反射带来的危害。 那么这样就一定是安全的吗？ 答案：当然不是
结合问题一优化后的代码看以下案例 首先创建一个类实现Serializable
public class SeriableSingleton implements Serializable {
/**
* 反序列化,
* 将已经持久化的字节码内容,转换为IO流
* 通过IO流的读取,进而将读取的内容转换为java对象
*/
private final static SeriableSingleton SINGLETON = new SeriableSingleton();
private SeriableSingleton(){};
public static SeriableSingleton getInstance(){
return SINGLETON;
}
}
使用反序列化攻击
public static void main(String[] args) {
SeriableSingleton s1 = null;
SeriableSingleton s2 = SeriableSingleton.getInstance();
FileOutputStream fos = null;
try{
fos = new FileOutputStream("SeriableSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (SeriableSingleton) ois.readObject();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1==s2);
}catch (Exception e){
e.printStackTrace();
}
}
结果: 不做演示了,说一下,结果是s1 和 s2 是两个对象 s1 == s2为false 原因： 序列化是将对象写入我们的磁盘中,反序列化的时候就会从我们的磁盘中进行读取,读取后转为内存对象。然后会重新分配内存，所以破坏了单例. 如何解决?
解决2：重新readResolve()方法在我们刚刚创建的实例对象SeriableSingleton中添加 readResolve()返回一个对象
private Object readResolve(){
return SINGLETON; //我们的实例名称
}
结果： 同样用刚刚编写的测试进行测试，结果是s1 和 s2 是1个对象 s1 == s2为true,这样就符合了单例的原则。 readResolve()从何而来 在这我稍微解释一下，我会专门整理一遍来阐述。 readResolve()不是谁的方法,它的作用是如果我们的反序列对象中存在此方法的话，在反序列化读取readObject（）方法中会查找是否存在name为readResolve的方法。 readResolve()为什么能阻止重新创建对象 readObject()会在内部反射进行查找有没有name为readResolve的方法,如果有的话会返回方法return的对象覆盖之前反序列出来的对象,实际上还是触发了两次。之前反序列化出来的对象没有了引用,自然的等待GC的回收。
三、注册式单例(枚举，容器) 3.1 枚举式单例枚举式单例的代码十分简单，并且能够很好解决安全问题。 《Effective Java》中也推荐我们使用枚举式单例
public enum EnumSingleton {
INSTANCE;
private Object data;
public Object getData() { return data; }
public void setData(Object data) { this.data = data; }
public static EnumSingleton getInstance(){
return INSTANC
}
}
测试代码1,和测试序列化代码方法一致。
public static void main(String[] args) {
//测试枚举式单例
EnumSingleton s1 = null;
EnumSingleton s2 = EnumSingleton.getInstance();
FileOutputStream fos = null;
try{
fos = new FileOutputStream("SeriableSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (EnumSingleton) ois.readObject();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1==s2);
}catch (Exception e){
e.printStackTrace();
}
}
测试1结果s1==s2。 测试2反射能否破坏枚举单例
public static void main(String[] args) {
Class cls = EnumSingleton.class;
Constructor constructor = cls.getDeclaredConstructor();
constructor.newInstance();
}
结果:失败->抛出java.lang.NoSuchMethodException的异常.->没找到方法？ 我们查看Enum的源码
protected Enum(String name, int ordinal) {
this.name = name;
this.ordinal = ordinal;
}
发现只有一个有参构造方法，好，那么我们在代码中加上参数, 修改一下
public static void main(String[] args) {
Class cls = EnumSingleton.class;
Constructor constructor = cls.getDeclaredConstructor(String.class,int.class);
constructor.setAccessible(true);
EnumSingleton enumSingleton = (EnumSingleton)constructor.newInstance("Ccc",18);
}
测试结果:失败->抛出java.lang.IllegalArgumentException: Cannot reflectively create enum objects.不能 用反射来创建枚举类型
为什么呢？ 我们来查看一下newInstance()的源码 
emmmmm,那么一脸懵逼 Modifier.ENUM是啥？？？？？ 继续看 
好像突然明白了。 newInstance()方法中做了强制性的判断，如果修饰符是Modifier.ENUM枚举类型,那么就会直接抛出异常。在JDK中已经对枚举式单例做个特别对待，所以在《Effective Java》中也推荐我们使用枚举式单例。 较为简单,
容器式写法适用于创建实例非常多的情况，便于管理。但是，是非线程安全的。在spring框架中应用广泛。
public class ContainerSingleton {
private ContainerSingleton(){};
private static Map ioc = new ConcurrentHashMap();
public static Object getBean(String className){
synchronized (ioc){
if(!ioc.containsKey(className)){
Object obj = null;
try{
obj = Class.forName(className).newInstance();
ioc.put(className,obj);
}catch (Exception e){
e.printStackTrace();
}
return obj;
}
return ioc.get(className);
}
}
}
关于单例模式在这就介绍这么些了，如果发现有补充的地方，我会继续添加，同时希望各位看过的伙伴们如果发现了问题能够及时批评指正，在此感谢。
