设计模式 - 单例模式（详解）看看和你理解的是否一样？

一、概述

单例模式是设计模式中相对简单且非常常见的一种设计模式，但是同时也是非常经典的高频面试题，相信还是有很多人在面试时会挂在这里。本篇文章主要针对单例模式做一个回顾，记录单例模式的应用场景、常见写法、针对线程安全进行调试（看得见的线程）以及总结。相信大家看完这篇文章之后，对单例模式有一个非常深刻的认识。

文章中按照常见的单例模式的写法，由浅入深进行讲解记录；以及指出该写法的不足，从而进行演进改造。

秉承废话少说的原则，我们下面快速开始

二、定义

单例模式(Singleton Pattern)是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。

单例模式是创建型模式。

三、应用场景

  1. 生活中的单例：例如，国家主席、公司 CEO、部门经理等。
  2. 在Java世界中：ServletContext、 ServletContextConfig 等;
  3. 在 Spring 框架应用中：ApplicationContext、数据库的连接池也都是单例形式。

四、常见的单例模式写法

单例模式主要有：饿汉式单例、懒汉式单例（线程不安全型、线程安全型、双重检查锁类型、静态内部类类型）、注册式（登记式）单例（枚举式单例、容器式单例）、ThreadLocal线程单例

下面我们来看看各种模式的写法。

1、饿汉式单例

饿汉式单例是在类加载的时候就立即初始化，并且创建单例对象。绝对线程安全，在线程还没出现以前就是实例化了，不可能存在访问安全问题。

Spring 中 IOC 容器 ApplicationContext 就是典型的饿汉式单例

优缺点

优点：没有加任何的锁、执行效率比较高，在用户体验上来说，比懒汉式更好。

缺点：类加载的时候就初始化，不管用与不用都占着空间，浪费了内存，有可能占着茅坑不拉屎。

写法

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午9:26
 */
public class HungrySingleton {
    // 1.私有化构造器
    private HungrySingleton (){}
    // 2.在类的内部创建自行实例
    private static final HungrySingleton instance = new HungrySingleton();
    // 3.提供获取唯一实例的方法（全局访问点）
    public static HungrySingleton getInstance(){
        return instance;
    }
}

还有另外一种写法，利用静态代码块的机制：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午10:46
 */
public class HungryStaticSingleton {
    // 1. 私有化构造器
    private HungryStaticSingleton(){}

    // 2. 实例变量
    private static final HungryStaticSingleton instance;

    // 3. 在静态代码块中实例化
    static {
        instance = new HungryStaticSingleton();
    }

    // 4. 提供获取实例方法
    public static HungryStaticSingleton getInstance(){
        return instance;
    }
}

测试代码,我们创建 10 个线程（具体线程发令枪 ConcurrentExecutor 在文末源码中获取）：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午11:17
 */
public class HungrySingletonTest {
    @Test
    public void test() {
        try {
            ConcurrentExecutor.execute(() -> {
                HungrySingleton instance = HungrySingleton.getInstance();
                System.out.println(Thread.currentThread().getName() + " : " + instance);
            }, 10, 10);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

测试结果：

pool-1-thread-6 : [email protected]37cce6
pool-1-thread-1 : [email protected]37cce6
pool-1-thread-9 : [email protected]37cce6
pool-1-thread-10 : [email protected]37cce6
pool-1-thread-2 : [email protected]37cce6
pool-1-thread-7 : [email protected]37cce6
pool-1-thread-5 : [email protected]37cce6
pool-1-thread-3 : [email protected]37cce6
pool-1-thread-4 : [email protected]37cce6
pool-1-thread-8 : [email protected]37cce6
...

可以看到，饿汉式每次获取实例都是同一个。

使用场景

这两种写法都非常的简单，也非常好理解，饿汉式适用在单例对象较少的情况。

下面我们来看性能更优的写法——懒汉式单例。

2、懒汉式单例

懒汉式单例的特点是:被外部类调用的时候内部类才会加载。

懒汉式单例可以分为下面这几种写法来。

简单懒汉式（线程不安全）

这是懒汉式单例的简单写法

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午10:55
 */
public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    private static LazySimpleSingleton instance = null;

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

我们创建一个多线程来测试一下，是否线程安全：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午11:12
 */
public class LazySimpleSingletonTest {

    @Test
    public void test() {
        try {
            ConcurrentExecutor.execute(() -> {
                LazySimpleSingleton instance = LazySimpleSingleton.getInstance();
                System.out.println(Thread.currentThread().getName() + " : " + instance);
            }, 5, 5);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

运行结果：

pool-1-thread-3 : [email protected]abe194f
pool-1-thread-5 : [email protected]abe194f
pool-1-thread-1 : [email protected]748e48d0
pool-1-thread-2 : [email protected]abe194f
pool-1-thread-4 : [email protected]abe194f

从测试结果来看，一定几率出现创建两个不同结果的情况，意味着上面的单例存在线程安全隐患。

至于为什么？由于篇幅问题，我们在后面一篇文章中利用测试工具进行详细的分析（这可能也是面试中面试官会问到的问题）。大家现在只需要知道简单的懒汉式会存在这么一个问题就行了。

简单懒汉式（线程安全）

通过对上面简单懒汉式单例的测试，我们知道存在线程安全隐患，那么，如何来避免或者解决呢？

我们都知道 java 中有一个synchronized可以来对共享资源进行加锁，保证在同一时刻只能有一个线程拿到该资源，其他线程只能等待。所以，我们对上面的简单懒汉式进行改造，给getInstance() 方法加上synchronized：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午10:55
 */
public class LazySimpleSyncSingleton {
    private LazySimpleSyncSingleton() {
    }

    private static LazySimpleSyncSingleton instance = null;

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

然后使用发令枪进行测试：

@Test
public void testSync(){
    try {
        ConcurrentExecutor.execute(() -> {
            LazySimpleSyncSingleton instance = LazySimpleSyncSingleton.getInstance();
            System.out.println(Thread.currentThread().getName() + " : " + instance);
        }, 5, 5);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

进行多轮测试，并观察结果，发现能够获取同一个示例：

pool-1-thread-3 : com.eamon.j[email protected]1a7e99de
pool-1-thread-2 : com.eamon.j[email protected]1a7e99de
pool-1-thread-5 : com.eamon.j[email protected]1a7e99de
pool-1-thread-1 : com.eamon.j[email protected]1a7e99de
pool-1-thread-4 : com.eamon.j[email protected]1a7e99de

线程安全问题是解决了，但是，用synchronized加锁，在线程数量比较多情况下，如果CPU分配压力上升，会导致大批量线程出现阻塞，从而导致程序运行性能大幅下降。

那么，有没有一种更好的方式，既兼顾线程安全又提升程序性能呢？答案是肯定的。

我们来看双重检查锁的单例模式。

双重检查锁懒汉式

上面的线程安全方式的写法，synchronized锁是锁在 getInstance() 方法上，当多个线程过来拿资源的时候，其实需要拿的不是getInstance()这个方法，而是getInstance()方法里面的instance 实例对象，而如果这个实例对象一旦被初始化之后，多个线程到达时，就可以利用方法中的 if (instance == null) 去判断是否实例化，如果已经实例化了就直接返回，就没有必要再进行实例化一遍。所以对上面的代码进行改造：

第一次改造：

/**
 * @author eamon.zhang
 * @date 2019-09-30 下午2:03
 */
public class LazyDoubleCheckSingleton {
    private LazyDoubleCheckSingleton() {
    }

    private static LazyDoubleCheckSingleton instance = null;

    public static LazyDoubleCheckSingleton getInstance() {
        // 这里判断是为了过滤不必要的同步加锁，因为如果已经实例化了，就可以直接返回了
        if (instance == null) {
            // 如果未初始化，则对资源进行上锁保护，待实例化完成之后进行释放
            synchronized (LazyDoubleCheckSingleton.class) {
                instance = new LazyDoubleCheckSingleton();
            }
        }
        return instance;
    }
}

这种方法行不行？答案肯定是不行，代码中虽然是将同步锁添加到了实例化操作中，解决了每个线程由于同步锁的原因引起的阻塞，提高了性能；但是，这里会存在一个问题：

  • 线程X和线程Y同时调用getInstance()方法，他们同时判断instance == null，得出的结果都是为null，所以进入了if代码块了
  • 此时线程X得到CPU的控制权 -> 进入同步代码块 -> 创建对象 -> 返回对象
  • 线程X执行完成了以后，释放了锁，然后线程Y得到了CPU的控制权。同样是 -> 进入同步代码块 -> 创建对象 -> 返回对象

所以我们明显可以分析出来：LazyDoubleCheckSingleton 类返回了不止一个实例！所以上面的代码是不行的！大家可以自行测试，我这里就不进行测试了！

我们再进行改造，经过分析，由于线程X已经实例化了对象，在线程Y再次进入的时候，我们再加一层判断不就可以解决 “这个” 问题吗？确实如此，来看代码：

/**
 * @author eamon.zhang
 * @date 2019-09-30 下午2:03
 */
public class LazyDoubleCheckSingleton {
    private LazyDoubleCheckSingleton() {
    }
    private static LazyDoubleCheckSingleton instance = null;
    public static LazyDoubleCheckSingleton getInstance() {
        // 这里判断是为了过滤不必要的同步加锁，因为如果已经实例化了，就可以直接返回了
        if (instance == null) {
            // 如果未初始化，则对资源进行上锁保护，待实例化完成之后进行释放（注意，可能多个线程会同时进入）
            synchronized (LazyDoubleCheckSingleton.class) {
                // 这里的if作用是：如果后面的进程在前面一个线程实例化完成之后拿到锁，进入这个代码块，
                // 显然，资源已经被实例化过了，所以需要进行判断过滤
                if (instance == null) {
                    instance = new LazyDoubleCheckSingleton();
                }
            }
        }
        return instance;
    }
}

大家觉得经过这样改造是不是就完美了呢？在我们习惯性的“讲道理”的思维模式看来，好像确实没什么问题，但是，程序是计算机在执行；什么意思呢？

在 instance = new LazyDoubleCheckSingleton(); 这段代码执行的时候，计算机内部并非简单的一步操作，也就是非原子操作，在JVM中，这一行代码大概做了这么几件事情：

  1. 给 instance 分配内存
  2. 调用 LazyDoubleCheckSingleton 的构造函数来初始化成员变量
  3. 将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）

但是在 JVM 中的即时编译器中存在指令重排序的优化；通俗的来说就是，上面的第二步和第三步的顺序是不能保证的，如果执行顺序是 1 -> 3 -> 2 那么在 3 执行完毕、2 未执行之前，被另外一个线程 A 抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程 A 会直接返回 instance，然后被程序调用，就会报错。

当然，这种情况是很难测试出来的，但是确实会存在这么一个问题，所以我们必须解决它，解决方式也很简单，就是 j 将 instance 加上 volatile 关键字。

所以相对较完美的实现方式是：

/**
 * @author eamon.zhang
 * @date 2019-09-30 下午2:03
 */
public class LazyDoubleCheckSingleton {
    private LazyDoubleCheckSingleton() {
    }

    private static volatile LazyDoubleCheckSingleton instance = null;

    public static LazyDoubleCheckSingleton getInstance() {
        // 这里判断是为了过滤不必要的同步加锁，因为如果已经实例化了，就可以直接返回了
        if (instance == null) {
            // 如果未初始化，则对资源进行上锁保护，待实例化完成之后进行释放（注意，可能多个线程会同时进入）
            synchronized (LazyDoubleCheckSingleton.class) {
                // 这里的if作用是：如果后面的进程在前面一个线程实例化完成之后拿到锁，进入这个代码块，
                // 显然，资源已经被实例化过了，所以需要进行判断过滤
                if (instance == null) {
                    instance = new LazyDoubleCheckSingleton();
                }
            }
        }
        return instance;
    }
}

测试代码见文末说明

静态内部类懒汉式

上面的双重锁检查形式的单例，对于日常开发来说，确实够用了，但是在代码中使用synchronized关键字 ，总归是要上锁，上锁就会存在一个性能问题。难道就没有更好的方案吗？别说，还真有，我们从类初始化的角度来考虑，这就是这里所要说到的静态内部类的方式。

废话不多说，直接看代码：

/**
 *
 * @author eamon.zhang
 * @date 2019-09-30 下午2:55
 */
public class LazyInnerClassSingleton {

    private LazyInnerClassSingleton() {
    }

    // 注意关键字final，保证方法不被重写和重载
    public static final LazyInnerClassSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        // 注意 final 关键字（保证不被修改）
        private static final LazyInnerClassSingleton INSTANCE = new LazyInnerClassSingleton();
    }
}

进行多线程测试：

pool-1-thread-9 : com.eamon.[email protected]88b7fa2
pool-1-thread-1 : com.eamon.[email protected]88b7fa2
pool-1-thread-6 : com.eamon.[email protected]88b7fa2
...

结果都是同一个对象实例。

结论

这种方式即解决了饿汉式的内存浪费问题，也解决了synchronized 所带来的性能问题

原理

利用的原理就是类的加载初始化顺序：

  1. 当类不被调用的时候，类的静态内部类是不会进行初始化的，这就避免了内存浪费问题；
  2. 当有方法调用 getInstance()方法时，会先初始化静态内部类，而静态内部类中的成员变量是 final 的，所以即便是多线程，其成员变量是不会被修改的，所以就解决了添加 synchronized 所带来的性能问题

首先感谢也恭喜大家能够看到这里，因为我想告诉你，上面所有的单例模式似乎还存在一点小问题 —— 暴力破坏。解决这一问题的方式就是下面提到的枚举类型单例。

至于缘由和为何枚举能够解决这个问题，同样，篇幅原因，我将在后面单独开一篇文章来说明。


下面我们先来讲讲注册式单例。

3、注册式（登记式）单例

注册式单例又称为登记式单例，就是将每一个实例都登记到某一个地方，使用唯一的标识获取实例。

注册式单例有两种写法:一种为容器缓存，一种为枚举登记。

先来看枚举式单例的写法。

枚举单例

废话少说，直接看代码，我们先创建EnumSingleton 类：

/**
 * @author eamon.zhang
 * @date 2019-09-30 下午3:42
 */
public enum EnumSingleton {
    INSTANCE;

    private Object instance;

    EnumSingleton() {
        instance = new EnumResource();
    }

    public Object getInstance() {
        return instance;
    }

}

来看测试代码：

/**
 * @author eamon.zhang
 * @date 2019-09-30 下午3:47
 */
public class EnumSingletonTest {

    @Test
    public void test() {
        try {
            ConcurrentExecutor.execute(() -> {
                EnumSingleton instance = EnumSingleton.INSTANCE;
                System.out.println(instance.getInstance());
            }, 10, 10);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

测试结果：

[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7
[email protected]e7

结果都一样，说明枚举类单例是线程安全的，且是不可破坏的；在 JDK 枚举的语法特殊性，以及反射也为枚举保驾护航，让枚举式单例成为一种比较优雅的实现。

枚举类单例也是《Effective Java》中所建议使用的。

容器式单例

注册式单例还有另外一种写法，利用容器缓存，直接来看代码：

创建ContainerSingleton类:

/**
 * @author EamonZzz
 * @date 2019-10-06 18:28
 */
public class ContainerSingleton {
    private ContainerSingleton() {
    }

    private static Map<String, Object> ioc = new ConcurrentHashMap<String, Object>();

    public static Object getBean(String className) {
        synchronized (ioc) {
            if (!ioc.containsKey(className)) {
                Object object = null;
                try {
                    object = Class.forName(className).newInstance();
                    ioc.put(className, object);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                return object;
            } else {
                return ioc.get(className);
            }
        }
    }
}

测试代码：

@Test
    public void test() {
        try {
            ConcurrentExecutor.execute(() -> {
                Object bean = ContainerSingleton
                        .getBean("com.eamon.javadesignpatterns.singleton.container.Resource");
                System.out.println(bean);
            }, 5, 5);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

测试结果：

[email protected]0f
[email protected]0f
[email protected]0f
[email protected]0f
[email protected]0f

容器式写法适用于创建实例非常多的情况，便于管理。但是，是非线程安全的。

其实 Spring 中也有相关容器史丹利的实现代码，比如 AbstractAutowireCapableBeanFactory 接口

至此，注册式单例介绍完毕。

五、拓展

ThreadLocal 线程单例

ThreadLocal 不能保证其创建的对象是唯一的，但是能保证在单个线程中是唯一的，并且在单个线程中是天生的线程安全。

看代码：

/**
 * @author EamonZzz
 * @date 2019-10-06 21:40
 */
public class ThreadLocalSingleton {
    private ThreadLocalSingleton() {
    }

    private static final ThreadLocal<ThreadLocalSingleton> instance = ThreadLocal.withInitial(ThreadLocalSingleton::new);

    public static ThreadLocalSingleton getInstance() {
        return instance.get();
    }
}

测试程序：

@Test
public void test() {
    System.out.println("-------------- 单线程 start ---------");
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println("-------------- 单线程 end ---------");
    System.out.println("-------------- 多线程 start ---------");
    try {
        ConcurrentExecutor.execute(() -> {
            ThreadLocalSingleton singleton = ThreadLocalSingleton.getInstance();
            System.out.println(Thread.currentThread().getName() + " : " + singleton);

        }, 5, 5);
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println("-------------- 多线程 end ---------");
}

测试结果：

-------------- 单线程 start ---------
com.eamo[email protected]1374fbda
com.eamo[email protected]1374fbda
com.eamo[email protected]1374fbda
com.eamo[email protected]1374fbda
com.eamo[email protected]1374fbda
-------------- 单线程 end ---------
-------------- 多线程 start ---------
pool-1-thread-5 : com.eamo[email protected]2f540d92
pool-1-thread-1 : com.eamo[email protected]3ef7ab4e
pool-1-thread-2 : com.eamo[email protected]604ffe2a
pool-1-thread-3 : com.eamo[email protected]50f41c9f
pool-1-thread-4 : com.eamo[email protected]40821a7a
-------------- 多线程 end ---------

从测试结果来看，我们不难发现，在主线程中无论调用多少次，获得到的实例都是同一个；在多线程环境下，每个线程获取到了不同的实例。

所以，在单线程环境中，ThreadLocal 可以达到单例的目的。这实际上是以空间换时间来实现线程间隔离的。

六、总结

单例模式可以保证内存里只有一个实例，减少了内存的开销；可避免对资源的浪费。

单例模式看起来非常简单，实现起来也不难，但是在面试中却是一个高频的面试题。希望大家能够彻底理解。


本篇文章所涉及的源代码：

github.com/eamonzzz

原文地址：https://www.cnblogs.com/eamonzzz/p/11633482.html

时间： 2024-10-29 18:24:20

设计模式 - 单例模式（详解）看看和你理解的是否一样？的相关文章

设计模式-单例模式详解

一.引言 单例模式应该算是23种设计模式中比较简单的,它属于创建型的设计模式,关注对象的创建. 二.概念 单例模式是23个“Gang Of Four”的设计模式之一,它描述了如何解决重复出现的设计问题,以设计灵活且可复用的面向对象软件,使对象的实现.更改.测试和重用更方便. 单例模式解决了以下问题: 如何确保类只有一个实例? 如何轻松地访问类的唯一实例? 如何控制类的实例化? 如何限制类的实例数量? 单例模式是如何解决以上问题的呢? 隐藏类的构造函数. 定义一个返回类的唯一实例的公共静态操作.

设计模式原则详解

我们在应用程序开发中,一般要求尽量两做到可维护性和可复用性.       应用程序的复用可以提高应用程序的开发效率和质量,节约开发成本,恰当的复用还可以改善系统的可维护性.而在面向对象的设计里面,可维护性复用都是以面向对象设计原则为基础的,这些设计原则首先都是复用的原则,遵循这些设计原则可以有效地提高系统的复用性,同时提高系统的可维护性. 面向对象设计原则和设计模式也是对系统进行合理重构的指导方针. 常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充. 1.单一职责

【设计模式】设计模式原则详解

我们在应用程序开发中,一般要求尽量两做到可维护性和可复用性.       应用程序的复用可以提高应用程序的开发效率和质量,节约开发成本,恰当的复用还可以改善系统的可维护性.而在面向对象的设计里面,可维护性复用都是以面向对象设计原则为基础的,这些设计原则首先都是复用的原则,遵循这些设计原则可以有效地提高系统的复用性,同时提高系统的可维护性. 面向对象设计原则和设计模式也是对系统进行合理重构的指导方针. 常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充. 1.单一职责

Android菜单详解（一）——理解android中的Menu

前言 今天看了pro android 3中menu这一章,对Android的整个menu体系有了进一步的了解,故整理下笔记与大家分享. PS:强烈推荐<Pro Android 3>,是我至今为止看到的最好的一本android书,中文版出到<精通Android 2>. 理解Android的菜单 菜单是许多应用程序不可或缺的一部分,Android中更是如此,所有搭载Android系统的手机甚至都要有一个"Menu"键,由此可见菜单在Android程序中的特殊性.An

Java设计模式----观察者模式详解

[声明] 欢迎转载,但请保留文章原始出处→_→ 生命壹号:http://www.cnblogs.com/smyhvae/ 文章来源:http://www.cnblogs.com/smyhvae/p/3899208.html 联系方式:[email protected] [正文] 一.观察者模式的定义: 简单地说,观察者模式定义了一个一对多的依赖关系,让一个或多个观察者对象监听一个主题对象.这样一来,当被观察者状态发生改变时,需要通知相应的观察者,使这些观察者对象能够自动更新.例如:GUI中的事件

Java集合详解5：深入理解LinkedHashMap和LRU缓存

Java集合详解5:深入理解LinkedHashMap和LRU缓存 今天我们来深入探索一下LinkedHashMap的底层原理,并且使用linkedhashmap来实现LRU缓存. 具体代码在我的GitHub中可以找到 https://github.com/h2pl/MyTech 文章首发于我的个人博客: https://h2pl.github.io/2018/05/11/collection5 更多关于Java后端学习的内容请到我的CSDN博客上查看:https://blog.csdn.net

9种Java单例模式详解（推荐）

单例模式的特点 一个类只允许产生一个实例化对象. 单例类构造方法私有化,不允许外部创建对象. 单例类向外提供静态方法,调用方法返回内部创建的实例化对象.  懒汉式(线程不安全) 其主要表现在单例类在外部需要创建实例化对象时再进行实例化,进而达到Lazy Loading 的效果. 通过静态方法 getSingleton() 和private 权限构造方法为创建一个实例化对象提供唯一的途径. 不足:未考虑到多线程的情况下可能会存在多个访问者同时访问,发生构造出多个对象的问题,所以在多线程下不可用这种

WmS详解(二)之如何理解Window和窗口的关系？基于Android7.0源码

上篇博客(WmS详解(一)之token到底是什么?基于Android7.0源码)中我们简要介绍了token的作用,这里涉及到的概念非常多,其中出现频率最高的要数Window和窗口这一对搭档了,那么我们今天就来看看到底我们该如何理解Android系统中的Window和窗口. 窗口这个概念,从不同的角度来看它的含义不一样,如果我们从WmS(WindowManagerService)的角度来看窗口,那么这个窗口并不是一个Window类,而是一个View.用户发来的消息被WmS接收之后并不能直接发给各个

【设计模式】单例模式详解

前言 博主只是一名大三学生,文章内容难免有不足之处,欢迎批评指正. 正文 转载请注明出处: http://blog.csdn.net/h28496/article/details/46403815 发 表 时 间: 2015年6月20日 单例模式的定义 一个类有且仅有一个实例,并且自行实例化向整个系统提供. 单例模式有三个要点: ① 这个类只能有一个实例: ② 必须是自行创建这个实例: ③ 必须是自行向整个系统提供这个实例. UML图: 单例模式的实现 假设一个场景:一个教师和一群学生在上课.学

Java设计模式图文详解

设计模式(Design Patterns) ——可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周