vlambda博客
学习文章列表

jdk源码中用到了哪些设计模式？

（1）单例模式

单例模式用于Runtime,Calendar和其他的一些类中。“饿汉式”是在不管你用的用不上，一开始就建立这个单例对象

（2）工厂模式

被用于各种不可变的类如Boolean，像Boolean.valueOf方法。

（3）装饰模式

装饰器模式被用于多个javaIO类

（4）代理模式

Jdk动态代理。

（5）迭代器模式

Java集合中的迭代器。

（6）策略模式

Arrays.sort()

（7）享元模式

Integer.valueof()

（8）模板方法模式

loadClass()双亲委派模型

（9）适配器模式

new Thread(new Furturetask(new Callable()))   创建线程的第三种方式 使用furturetask来适配callable接口

工厂模式和简单工厂模式的区别

1、简单工厂模式中包含判断什么对象的逻辑，而工厂方法模式则需要调用者判断要实例化什么具体类型的工厂进而创建出想要的对象。

2、当增加新类时，简单工厂模式需要修改工厂类，而工厂方法模式不需要，因此工厂方法模式遵守了开闭原则，而简单工厂模式没遵守。

3、简单工厂模式因为采用了静态方法，所以不利于继承，而工厂方法模式恰恰相反，需要利用到继承来从抽象工厂中派生出各种各样的具体工厂。

静态代理模式和动态代理模式的区别

静态： 由程序员创建代理类。在程序运行前要代理的对象就已经指定了。

动态： 在程序运行时运用反射机制动态创建而成。(InvocationHandler的应用)

设计模式6大原则，以及哪些设计模式遵循了哪些原则

（1）单一职责原则：

理解： 不同的类具备不同的职责，各司其职。做系统设计是，如果发现有一个类拥有了两种职责，那么就要问一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分开，千万不要让一个类干的事情太多。

（2）开放封闭原则

理解： 类、模块、函数，可以去扩展，但不要去修改。如果要修改代码，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能保证对整个架构不会产生任何影响，那就没必要搞的那么复杂，直接改这个类吧。

总结： 对软件实体的改动，最好用扩展而非修改的方式。

（3）里式替换原则

理解： 父类可被子类替换，但反之不一定成立。也就是说，代码中可以将父类全部替换为子类，程序不会出现异常，但反过来就不一定了。

总结： 在继承类是，务必重写（override）父类中所有的方法，尤其需要注意父类的protected方法（它们往往是让你重写的），子类尽量不要暴露自己的public方法供外界调用。

（4）最少知识原则

理解： 尽量减少对象之间的交互，从而减小类之间的耦合。在做系统设计时，不要让一个类依赖于太多其他的类，需尽量减小依赖关系，否则死都不知道怎么死的。

总结： 一定要做到：低耦合、高内聚。

（5）接口隔离原则

理解： 不要对外暴露没有实际意义的接口。也就是说，尽量保证接口的实用性。当需要对外暴露接口时，需要再三斟酌，若没必要对外提供就删了吧，因为一旦提供了就意味着，将来要多做一件事情，何苦给自己找事做呢。

总结： 不要对外暴露没有实际意义的接口。

（6）依赖倒置原则

理解： 高层模块不应该依赖于底层模块，而应该依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。应该面向接口编程，不该面向实现类编程。面向实现类编程相当于就事论事，那是正向依赖；面向接口编程，相当于透过现象看本质，抓住事务的共性，那就是反向依赖，即依赖倒置。

总结： 面向接口编程，提取出事务的本质和共性。

单例设计模式

懒汉式单例 线程不安全

当被问到要实现一个单例模式时，很多人的第一反应是写出如下的代码，包括教科书上也是这样教我们的。

public class Singleton {
    private static Singleton uniqueInstance;
    private Singleton (){}

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

这段代码简单明了，而且使用了懒加载模式，但是却存在致命的问题。当有多个线程并行调用 getInstance() 的时候，就会创建多个实例。也就是说在多线程下不能正常工作。

懒汉式单例 线程安全

为了解决线程安全的问题，最简单的方法是将整个 getInstance() 方法设为同步（synchronized）。

public class Singleton {
    private static Singleton uniqueInstance;
    private Singleton (){}
    
    public static synchronized Singleton getInstance() {
        if (uniqueInstance == null) {
            uniqueInstance = new Singleton();
        }
        return uniqueInstance;
    }
}

虽然做到了线程安全，并且解决了多实例的问题，但是它并不高效。因为在任何时候只能有一个线程调用 getInstance() 方法。但是同步操作只需要在第一次调用时才被需要，即第一次创建单例实例对象时。这就引出了双重检验锁。

饿汉式单例+ 静态final变量 线程安全

这种方法非常简单，因为单例的实例被声明成 static 和 final 变量了，在第一次加载类到内存中时就会初始化，所以创建实例本身是线程安全的。

public class Singleton{
    //类加载时就初始化
    private static final Singleton uniqueInstance = new Singleton();
    
    private Singleton(){}

    public static Singleton getInstance(){
        return uniqueInstance;
    }
}

这种写法如果完美的话，就没必要在啰嗦那么多双检锁的问题了。缺点是它不是一种懒加载模式（lazy initialization），单例会在加载类后一开始就被初始化，即使客户端没有调用 getInstance()方法。饿汉式的创建方式在一些场景中将无法使用：譬如 Singleton 实例的创建是依赖参数或者配置文件的，在 getInstance() 之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。

双重检查加锁单例 线程安全

双重检验加锁模式（double checked locking pattern），是一种使用同步块加锁的方法。程序员称其为双重检查锁，因为会有两次检查 uniqueInstance == null，一次是在同步块外，一次是在同步块内。为什么在同步块内还要再检验一次？因为可能会有多个线程一起进入同步块外的 if，如果在同步块内不进行二次检验的话就会生成多个实例了。

public class Singleton {
    private static Singleton uniqueInstance;
    private Singleton (){}
    
    public static Singleton getSingleton() {
        if (uniqueInstance == null) {                         //Single Checked
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {                 //Double Checked
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

这段代码看起来很完美，很可惜，它是有问题。主要在于uniqueInstance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。

• 给 uniqueInstance 分配内存

• 调用 Singleton 的构造函数来初始化成员变量

• 将uniqueInstance对象指向分配的内存空间（执行完这步 uniqueInstance 就为非 null 了） 但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时uniqueInstance已经是非 null 了（但却没有初始化），所以线程二会直接返回 uniqueInstance，然后使用，然后顺理成章地报错。

我们只需要将 uniqueInstance 变量声明成 volatile 就可以了。

public class Singleton {
    private volatile static Singleton uniqueInstance; //声明成 volatile
    private Singleton (){}

    public static Singleton getSingleton() {
        if (uniqueInstance == null) {                         
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {       
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

有些人认为使用 volatile 的原因是可见性，也就是可以保证线程在本地不会存有 uniqueInstance 的副本，每次都是去主内存中读取。但其实是不对的。使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。

但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即使将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。

相信你不会喜欢这种复杂又隐含问题的方式，当然我们有更好的实现线程安全的单例模式的办法。

静态内部类单例  线程安全

这种方法是《Effective Java》上所推荐的。

public class Singleton {  
    private static class SingletonHolder {  
        private static final Singleton uniqueInstance = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
        return SingletonHolder.uniqueInstance; 
    }  
}

这种写法仍然使用JVM本身机制保证了线程安全问题；由于 SingletonHolder 是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒加载的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。

枚举单例 线程安全

用枚举写单例实在太简单了！这也是它最大的优点。下面这段代码就是声明枚举实例的通常做法。

public enum EasySingleton{
    INSTANCE;
}

我们可以通过EasySingleton.INSTANCE来访问实例，这比调用getInstance()方法简单多了。创建枚举默认就是线程安全的，所以不需要担心double checked locking，而且还能防止反序列化导致重新创建新的对象。但是还是很少看到有人这样写，可能是因为不太熟悉吧。

谈一谈，开发中都用到了 哪些设计模式? 用在什么场合?

把老哥B站上讲设计模式那个视频看了

Spring单例和Java单例（设计模式）有什么区别？

Java单例由Java类加载器确定范围，Spring单例由容器上下文确定范围。

从根本上讲，这意味着在Java中，可以确保单例仅在加载它的类加载器的上下文中才是真正的单例。尽管您在代码中尽力防止它发生，但其他类加载器也应该能够创建它的另一个实例（前提是这些类加载器不在同一类加载器层次结构中）。

在Spring中，如果您可以在两个不同的上下文中加载单例类，然后再次打破单例概念。

因此，总而言之，如果Java无法在给定的类加载器中创建该类的多个实例，则Java将其视为一个单例，而如果Java无法在给定的容器/中创建一个类的多个实例，则Spring将其视为一个单例。上下文。