不得不说，这样的做法确实达到了单例模式的要求，正常情况下系统中只有一个Singleton的对象。但是如果存在并发的情况呢？两个用户同时访问该类的获取器，此时假设Singleton对象还未被实例化，那么系统将会两次调用构造方法，这样一来系统中就会存在两个Singleton类的实例。说明这种方式的单例没有考虑到并发情况，说明面试者只是粗略的了解单例模式，并没有加以深入思考，想让面试官满意？呵呵。。。。。。

Java相较于C++而言个人认为编程的难易度上来说要容易很多。在考虑线程同步时一个synchronized关键字便能解决普通加锁问题。synchronized关键字，当它用来修饰一个方法或者一个代码块的时候，能够保证在同一时刻最多只有一个线程执行该段代码。也就是说当两个线程同时访问类中synchronized方法或代码块时，只能有一个线程执行其代码，另一个只能等待当前线程调用结束后才能访问。这下子单例的实现就so easy了！只要对代码稍加改动即可：

这样的写法面试官会觉得你这个面试者在思考问题的时候比较全面，考虑到并发的情况，相较之前的方式面试官会觉得：少年，很有前途哦！

然而光是让面试官看好是不够的，我们要让他欣赏，通过单例这样的小问题便能拿到offer。也就是说第二种实现方式是可以进行优化的。如何优化呢？我们看到，当前系统中每次调用获取方法时便会进行加锁，而加锁需要的时间便是我们可以进行优化的地方。现在我所想的是我们只需要在第一次调用时加一次锁往后便再也不不需要加锁了，这样一来便省下了每次调用加锁的时间，虽然计算机执行加锁的时间很短但久而久之也是相当长的一段时间。

那么怎么实现呢？这需要引入另一个关键字volatile。volatile修饰的话就可以确保instance = new Singleton();对应的指令不会重排序（JVM当发现代码执行顺序变化但结果不变时可能会改变执行顺序来提升自身性能。好坑。。。），也是线程安全的。

如何理解呢？

线程 1 进入get 方法。

由于single 为null，线程 1 在 //1 处进入 synchronized块。

线程 1 被线程 2 预占。

线程 2 进入get 方法。

由于single 仍旧为null，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。

线程 2 被线程 1 预占。

线程 1 执行，由于在 //2 处实例仍旧为null，线程 1 还创建一个Singleton对象并将其引用赋值给single。

线程 1 退出 synchronized块并从 get方法返回实例。

线程 1 被线程 2 预占。

线程 2 获取 //1 处的锁并检查single 是否为null。

由于single 是非 null的，并没有创建第二个Singleton对象，由线程 1 创建的对象被返回。

像这样的程序，面试官看完还能不给你offer吗？骚年，前途不可限量啊！