单例模式——sington

单例模式——sington

有一些对象其实我们只需要一个，比如:线程池、缓存、充当显卡等设备的驱动程序的对象。这类对象只能有一个实例，否则会出现很多问题，资源消耗过多、数据不一致等。

定义

　　确保一个类只有一个实例，并提供一个全局的访问点。

类图

　　

说明：1.一个private static的Singleton实例变量instance.

　　　2.一个public static 的getInstance方法，返回instance。

　　　3.一个私有构造方法

经典实现

public class Singleton {
    private static Singleton instance = null;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

}

 分析：为了保证类只有一个实例，Singleton类的构造方法需为private的这样外界不能通过new直接实例化对象，而只能通过Singleton提供的全局访问点getinstance方法获得，这样就保证了类对象的惟一性。

问题：这样写看上去很完美，实事上是这样吗？可，现实是残酷的，呵呵。

假设，我们有两个线程A,B同时访问上面的代码。假设A线程执行完if(instance == null)后时间片用完，然后B线程来访问上面的代码，假设B线程执行完了instance = new Singleton();即现在Singleton已经有了一个实例化对象。然后B时间片用完A线程回来接着执行，A线程要执行instance = new Singleton();这样就会带来一个问题，Singleton被实例化了两次。显然，这不是我们想要的，应该怎么解决呢？

解决方案：

　　我们知道上面的问题是由线程同步问题造成的，那么我们可以直接将getinstance方法加上线程同步锁既可，如下：

1 public static synchronized Singleton getInstance() {
2         if (instance == null) {
3             instance = new Singleton();
4         }
5         return instance;
6     }

 新的问题：这样的确是没同步问题了，但线程同步会造成性能的降低，并且对于我们这种情况，我们实际上只需要在第一次进行同步(instance为null时)，以后都不需要进行同步了，可我们上面的代码每次执行都会进行同步，显然这是不合理的，那应该怎么解决呢？

方案A：提前初始化instance。

　　如果我们的程序总是创建并使用单例实例，或者在创建和运行方面的负担不太繁重，你可以提前实例化instance,如下所示：

 1 public class Singleton {
 2     private static Singleton instance = new Singleton();
 3 
 4     private Singleton() {
 5     }
 6 
 7     public static synchronized Singleton getInstance() {
 8         return instance;
 9     }
10 
11 }

 利用此方法，我们可以在JVM加载这个类时就创建此惟一的对象。JVM保证在任何线程访问instance之前，一定先创建此实例。

 方案B：双重检查锁 　　

 1 public static Singleton getInstance()
 2 {
 3   if (instance == null)
 4   {
 5     synchronized(Singleton.class) {  
 6       if (instance == null)          
 7         instance = new Singleton();  
 8     }
 9   }
10   return instance;
11 }

 通过此方法既可保证只在instance为null的时候才进行同步，保证了性能。

 

 

分类: DesignPattern

小菜的系统框架界面设计-序言

• "如果编程之道是完美的，那么操作系统就是完美的；如果操作系统是完美的，那么编译程序就是完美的；如果编译程序是完美的，那么应用程序就是完美的。于是，用户满意之极，和谐应运而生。"

——《编程之道》开篇语

　　软件用户界面的发展经历了从简单到复杂、从低级到高级的过程，用户界面在软件系统中的价值比重越来越高。很大程度上影响着软件的命运，因为广大用户对软件的评价主要来源于他们操作用户界面的感受。同类软件越多，选择余地越大，购买者对软件用户界面就越挑剔。

        好”的软件意味着“实用、易用、美观”，户才真正有资格说软件“好或坏”。如果用户对软件很不满意，开发人员不要有逆反情绪：“从哪里找来的笨蛋用户?”,如果换作我是用户，我对界面的要求甚至更高，曾经我在做项目顾问时，给甲方的MES系统界面设计从美观，操作方式等方面提出了很多缺陷，估计对方开发人员都记恨我了，每次见到我躲得远远的，生怕我跟他主管提到，他又要忙一阵子修改了，哈哈~~我真成罪人啦!

      在一年多的系统开发中，我总结了一些失败的案例，主要有两方面：

• 我们开发人员本身没有专门定制一些现成的组件，开发效率低，而且质量和性能不能保证。
• 老板不愿意购买第三方插件版权，但却对用户界面要求很高
• 无法满足客户对界面的美观需求,用户体验欠佳。

     所以，我现在要写一个基于制造类管理系统的框架界面设计系列，我很喜欢一本书《大话设计模式》的作者,迷伍大哥，他写的书让我百看不厌，我就是像书中说的那个小菜，所以我把这个学习系列叫《小菜的系统框架界面设计》，主要是总结工作中遇到的系统框架设计问题，和封装系统开发过程中常用到的一些组件，我的目标是软件开发就像制造业的组装一样，经过使用我的半成品就可以快速组装成为成品

——一个完整的系统框架，我罗列设计中涉及到的方方面面注意的问题，陈述我的设计原理和思路，如果有不小心跳进我博客看到我的东西,请朋友拍砖评论，多提宝贵意见，我不是为了表示我有这方面丰富的经验，我只是想通过这样一个方式，收集一些专业人士的改进意见，不断做到尽可能完美，同时也让更多跟我同行业正在努力的朋友，也能从中学到些东西，少走弯路，本人也有过学习困难的经历，甚至我为了想研究某一模块的技术点时，请教园中的一些朋友,他们还要问我收报酬费，其实我觉得这正常，这社会就这样，一个利益和金钱的年代。但是我为了学习，也花了点小钱，算是小投资图大收获。但我个人比效喜欢分享，把学到的有用的知识分享给我的朋友—“赠人玫瑰，手有余香”。

     我设计的界面组件系列，主要是一个基于C#开发平台支持换肤功能的系统框架组件集，支持模板样式快速成型和个性化定制。

 

 

 

 

 

 

分类: 系统框架设计