单例应该考虑的一些问题

说到单例模式可能大家都不陌生,都会用,但是如何才能写出一个健壮的单例模式,并扩展成适合项目的单例模式其实也是需要仔细思考的问题.通常我们实现单例的方式有几种,在初始化的时候创建对象,另一种方式则是通过方法判断是否为空,并创建对象返回。貌似看上去没什么太大差距,但事实上通过初始化时创建对象是线程安全的,通过方法获得对象是需要考虑相称安全的。
说到这里,不得不说一下关于线程的问题,其实在最早的单核CPU时代，我们是不需要考虑创建对象的线程安全的,毕竟CPU在同一时间点只能做一件事情,但是在这个拥有双核,四核的时代,我们不得不考虑这个问题.所以说我们不得不在判断以及创建对象的时候对其进行同步,但是仅仅在此同步就OK了嘛,当然不是。因为就其本身也会存在同步的问题,用一个例子来说明这一点,假如我们现在有1台32位的双核PC,当其处理64位Long型数据时,其实是会将其分为高32位,与第32位两部分来处理的,如果在非线程安全的情况下,则有几率导致一些脏数据.也因此出现了volatile来保证其原子性,并在JDK1.5以后出现了concurrent的基本类型.(-.-废话多了点儿)
所以,如果不想在一开始就创建对象占用空间的话,那么最好采用懒加载的方式,在初始化的时候将对象设置为静态私有成员变量,并保持其原子性,并在调用方法判断并创建对象时对其进行同步,以保证创建出唯一的对象.到此,我们才能真正保证其唯一性。
但是,往往我们的使用场景不是仅此而已,我们还会遇到序列化与反序列化的问题,我们还需要保证其序列化与反序列化是同一对象,所以我们必须对readSolve方法。
这样我们基本就能创建出一个健壮的单例对象了。
现在我们虽然能创建健壮的单例对象了,但是又有新的问题值得我们去思考了,什么时候我们应该使用单例?
这还用说么,什么Connection,Factory等等,都是我们使用的场景.但是你觉得这真的就合适吗?就我个人而言,我觉得一个对象是否应该是单例通常都是由我们的使用场景所决定的,所以说像这样硬编码一开始就决定对象是单例,往往是不太科学的,其应该由容器所决定,是可配置的,这样才能更加灵活。
从而也衍生出了变种的多例,及线程池,连接池等等.