深入理解设计模式面经

1 讲讲工厂方法模式，

1.1 给我一个java的demo

工厂方法模式是一种创建型设计模式，它提供了一个接口用于创建对象，但允许子类修改将要创建的对象类型。这种模式抽象了对象的创建过程，使得代码可以在不知道创建的对象具体类的情况下工作。

基本结构：

• Product（产品）: 这是创建的对象的接口。
• ConcreteProduct（具体产品）: 这是实现Product接口的具体类。
• Creator（创建者）: 这是一个抽象类，它定义了一个抽象的工厂方法。这个方法返回一个Product类型的对象。
• ConcreteCreator（具体创建者）: 这是继承自Creator的类，它实现了工厂方法来生产具体的产品。

示例：

假设我们要设计一个UI库，其中有多种按钮类型。我们可以使用工厂方法模式来设计这个库。

// Product
interface Button {
    void render();
}

// ConcreteProductA
class WindowsButton implements Button {
    @Override
    public void render() {
        System.out.println("Rendering a Windows-style button.");
    }
}

// ConcreteProductB
class MacButton implements Button {
    @Override
    public void render() {
        System.out.println("Rendering a Mac-style button.");
    }
}

// Creator
abstract class Dialog {
    // This is the factory method
    protected abstract Button createButton();

    public void render() {
        // use the factory method to create a product object
        Button button = createButton();
        button.render();
    }
}

// ConcreteCreatorA
class WindowsDialog extends Dialog {
    @Override
    protected Button createButton() {
        return new WindowsButton();
    }
}

// ConcreteCreatorB
class MacDialog extends Dialog {
    @Override
    protected Button createButton() {
        return new MacButton();
    }
}

public class FactoryMethodDemo {
    public static void main(String[] args) {
        Dialog windowsDialog = new WindowsDialog();
        windowsDialog.render();

        Dialog macDialog = new MacDialog();
        macDialog.render();
    }
}

在上面的示例中，Dialog是一个创建者，它有一个工厂方法createButton()。具体的对话框（如WindowsDialog和MacDialog）实现了这个工厂方法来创建具体的按钮。

1.2 相比于简单工厂模式，这种工厂方法模式有什么好处呢

工厂方法模式和简单工厂模式都是用于创建对象的，但它们在结构和意图上有所不同。下面是工厂方法模式相比于简单工厂模式的一些优势：

1. 更好的可扩展性:

   • 简单工厂：当需要添加新的产品时，你可能需要修改已有的工厂类，这违反了开闭原则（对扩展开放，对修改封闭）。
   • 工厂方法：只需添加新的具体创建者（ConcreteCreator）和具体产品（ConcreteProduct），无需修改已有的代码。这使得系统更加模块化和可扩展。

2. 单一职责原则：

   • 在工厂方法模式中，每个具体创建者（ConcreteCreator）都只负责生产一种具体产品（ConcreteProduct）。这符合单一职责原则。
   • 而在简单工厂模式中，一个工厂类可能需要处理多种产品的创建，这可能导致工厂类的代码过于复杂和臃肿。

3. 更好地与子类合作：

   • 工厂方法模式允许子类提供其自己版本的对象实例化逻辑，这增加了系统的灵活性。
   • 简单工厂模式中，创建对象的逻辑被固定在工厂类中，难以做出细粒度的定制。

4. 更好的封装：

   • 在工厂方法模式中，每种产品的创建逻辑都被封装在相应的具体创建者中。这使得创建逻辑和产品本身更紧密地结合。
   • 而在简单工厂模式中，所有的创建逻辑都集中在一个工厂类中，这可能导致工厂类过于庞大。

5. 动态指定工厂：

   • 在工厂方法模式中，你可以动态地更改或指定使用哪个工厂来创建对象，提供了更大的灵活性。
   • 在简单工厂模式中，通常基于一个参数或条件来决定创建哪种对象，这限制了其动态性。

尽管工厂方法模式提供了这些优点，但它也带来了更多的类和更复杂的结构。对于某些简单的情况，简单工厂模式可能更为合适。设计模式的选择应该基于项目的具体需求和上下文。

2 策略模式

2.1 实现方式：菜鸟教程：策略模式

步骤 1
创建一个接口。
Strategy.java
public interface Strategy {
   public int doOperation(int num1, int num2);
}

步骤 2
创建实现接口的实体类。

OperationAdd.java
public class OperationAdd implements Strategy{
   @Override
   public int doOperation(int num1, int num2) {
      return num1 + num2;
   }
}

OperationSubtract.java
public class OperationSubtract implements Strategy{
   @Override
   public int doOperation(int num1, int num2) {
      return num1 - num2;
   }
}
OperationMultiply.java
public class OperationMultiply implements Strategy{
   @Override
   public int doOperation(int num1, int num2) {
      return num1 * num2;
   }
}

步骤 3

创建 Context 类。

Context.java
public class Context {
   private Strategy strategy;
 
   public Context(Strategy strategy){
      this.strategy = strategy;
   }
 
   public int executeStrategy(int num1, int num2){
      return strategy.doOperation(num1, num2);
   }
}
步骤 4

使用 Context 来查看当它改变策略 Strategy 时的行为变化。

StrategyPatternDemo.java
public class StrategyPatternDemo {
   public static void main(String[] args) {
      Context context = new Context(new OperationAdd());    
      System.out.println("10 + 5 = " + context.executeStrategy(10, 5));
 
      context = new Context(new OperationSubtract());      
      System.out.println("10 - 5 = " + context.executeStrategy(10, 5));
 
      context = new Context(new OperationMultiply());    
      System.out.println("10 * 5 = " + context.executeStrategy(10, 5));
   }
}
这是一个通用的策略模式demo，我现在想使用反射机制来融入这个代码中，比如根据前端传过来的字符串，创建相应的实现类

2.2 使用反射机制来使用这种模式

菜鸟教程上提供的策略模式demo是实现的一种，还有一种可以通过反射实现这个策略模式

使用反射可以动态地创建类的实例。以下是一个修改版的策略模式，使用反射机制根据传入的字符串来创建相应的策略实现类：

1. 保持 Strategy 接口以及其实现类不变。

2. 在 Context 类中加入一个基于字符串的构造函数，通过反射来创建策略对象。

public class Context {
    private Strategy strategy;

    // 原来的构造函数
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    // 新增的基于字符串的构造函数
    public Context(String className) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        this.strategy = (Strategy) Class.forName(className).newInstance();
    }

    public int executeStrategy(int num1, int num2) {
        return strategy.doOperation(num1, num2);
    }
}

3. 在 StrategyPatternDemo 中使用基于字符串的 Context 构造函数。

public class StrategyPatternDemo {
    public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        // 基于策略对象的示例
        Context contextByObject = new Context(new OperationAdd());
        System.out.println("10 + 5 = " + contextByObject.executeStrategy(10, 5));

        // 基于字符串的示例
        Context contextByString = new Context("OperationAdd");
        System.out.println("10 + 5 = " + contextByString.executeStrategy(10, 5));
    }
}

请注意，基于字符串的 Context 构造函数可能会抛出异常，因此需要适当地处理它们。在此示例中，为了简洁起见，我们仅在 main 方法中抛出了它们。在实际应用中，您应该提供更细致的异常处理逻辑。

还要注意，这里假设策略类与 StrategyPatternDemo 在同一个包中，因此类名没有包前缀。如果您的策略类在其他包中，请提供完整的类名，例如 “com.example.OperationAdd”。

2.4 通过Map+策略模式实现基本计算器的扩展

为了将策略模式应用于此算法题，我们可以为每种操作定义一个策略，并使它们易于扩展以支持新的操作，如 % 求模操作。以下是如何做到这一点的步骤：

1. 定义策略接口:
   这将为所有操作定义一个共同的接口。

public interface Operation {
    long execute(long num1, long num2);
}

2. 实现策略接口:
   为每种操作实现策略接口。

public class Addition implements Operation {
    @Override
    public long execute(long num1, long num2) {
        return num1 + num2;
    }
}

public class Subtraction implements Operation {
    @Override
    public long execute(long num1, long num2) {
        return num1 - num2;
    }
}

public class Multiplication implements Operation {
    @Override
    public long execute(long num1, long num2) {
        return num1 * num2;
    }
}

public class Division implements Operation {
    @Override
    public long execute(long num1, long num2) {
        return num1 / num2;
    }
}

public class Modulo implements Operation {
    @Override
    public long execute(long num1, long num2) {
        return num1 % num2;
    }
}

3. 定义策略管理器:
   这将管理所有的策略，并根据提供的运算符返回相应的策略。

public class OperationManager {
    private static final Map<String, Operation> operations = new HashMap<>();

    static {
        operations.put("+", new Addition());
        operations.put("-", new Subtraction());
        operations.put("*", new Multiplication());
        operations.put("/", new Division());
        operations.put("%", new Modulo());
    }

    public static Operation getOperation(String operator) {
        return operations.get(operator);
    }
}

4. 修改原有代码以使用策略模式:

原有的计算代码：

public static int compute(String op,int a,int b) {
	 int res=a;
	 if (op.equals("+")){
  		res +=num;
     }else if(op.equals("-")) {
        res -=num;
     }else if(op.equals("*")) {
        res *=num;
     }else if(op.equals("/")) {
        res /=num;
     }
     return res;
}

在 compute 方法中，根据运算符从 OperationManager 获取策略并执行相应的操作。

public static int compute(String op,int a,int b) {
	Operation operation = OperationManager.getOperation(op);
	if (operation != null) {
		res = operation.execute(a, b);
    }
    return res;
}

这样，如果你现在想增加一个新的操作，只需要实现 Operation 接口，并在 OperationManager 中注册新的策略即可。这符合开放/封闭原则，使代码更易于维护和扩展。

2.4 策略模式和模板模式如何结合呢？结合下单系统

当然可以。以下是一个简化但更完整的在线订单处理程序，结合了模板模式和策略模式：

订单处理框架：

1. 验证订单
2. 应用折扣
3. 支付
4. 生成收据

我们将允许不同的支付策略，并在某些步骤中为子类提供默认实现，同时允许它们覆盖这些实现。

// 定义支付策略接口
interface PaymentStrategy {
    void pay(double amount);
}

// 信用卡支付策略实现
class CreditCardPayment implements PaymentStrategy {
    private String cardNumber;
    private String expiryDate;

    public CreditCardPayment(String cardNumber, String expiryDate) {
        this.cardNumber = cardNumber;
        this.expiryDate = expiryDate;
    }

    @Override
    public void pay(double amount) {
        // 简化为一个输出
        System.out.println("Paid " + amount + " using credit card ending with " + cardNumber.substring(cardNumber.length() - 4));
    }
}

// PayPal支付策略实现
class PaypalPayment implements PaymentStrategy {
    private String email;

    public PaypalPayment(String email) {
        this.email = email;
    }

    @Override
    public void pay(double amount) {
        // 简化为一个输出
        System.out.println("Paid " + amount + " using PayPal with email: " + email);
    }
}

// 订单处理抽象类（模板模式）
abstract class OrderProcessor {
    protected double orderAmount;

    public OrderProcessor(double orderAmount) {
        this.orderAmount = orderAmount;
    }

    // 这是模板方法
    public final void processOrder() {
        validateOrder();
        applyDiscount();
        paymentStrategy.pay(orderAmount);
        generateReceipt();
    }

    // 默认验证实现
    protected void validateOrder() {
        System.out.println("Order validated.");
    }

    // 默认折扣实现
    protected void applyDiscount() {
        // 这里只是一个简单的示例
        orderAmount *= 0.95; 
        System.out.println("Discount applied. New amount: " + orderAmount);
    }

    // 子类可以覆盖的收据生成步骤
    protected abstract void generateReceipt();

    // 使用策略模式的支付步骤
    protected PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.paymentStrategy = strategy;
    }
}

// 一个特定的订单处理实现
class OnlineOrderProcessor extends OrderProcessor {
    public OnlineOrderProcessor(double orderAmount) {
        super(orderAmount);
    }

    @Override
    protected void generateReceipt() {
        System.out.println("Online receipt generated for amount: " + orderAmount);
    }
}

// 主程序
public class Main {
    public static void main(String[] args) {
        OrderProcessor order = new OnlineOrderProcessor(100);
        order.setPaymentStrategy(new CreditCardPayment("1234567812345678", "12/25"));
        order.processOrder();

        System.out.println("-----------");

        OrderProcessor anotherOrder = new OnlineOrderProcessor(150);
        anotherOrder.setPaymentStrategy(new PaypalPayment("user@example.com"));
        anotherOrder.processOrder();
    }
}

在这个示例中，我们使用了模板模式来定义订单处理的基本步骤，并使用策略模式为支付步骤提供不同的策略。

2.5 如何让策略模式只生产单例策略

2.5.1 方法一：参考2.3中，先使用map预先将一个实例存储起来，随后每一次请求调用的时候都返回这个缓存

2.5.2 方法二：使用final static字段

你正确地指出了在给定的策略模式示例中，每次调用都会创建一个新的策略对象。在高并发场景下，这种对象的频繁创建和垃圾收集可能会导致性能问题。

解决这一问题的一种方法是使用所谓的“Flyweight”模式，或者更简单地说，是预先创建并重用策略对象。考虑到策略对象（如 OperationAdd、OperationSubtract 和 OperationMultiply）是无状态的，它们可以被多个线程安全地共享。

一个简单的做法是将策略对象作为静态常量预先创建（策略接口及其实现类不变）：

public class OperationAdd implements Strategy{
   public static final OperationAdd INSTANCE = new OperationAdd();
   
   private OperationAdd() {}
   
   @Override
   public int doOperation(int num1, int num2) {
      return num1 + num2;
   }
}

// 对于其他策略类，也可以这样做

然后，你可以这样使用它：

public class StrategyPatternDemo {
   public static void main(String[] args) {
      Context context = new Context(OperationAdd.INSTANCE);    
      System.out.println("10 + 5 = " + context.executeStrategy(10, 5));

      context = new Context(OperationSubtract.INSTANCE);      
      System.out.println("10 - 5 = " + context.executeStrategy(10, 5));

      context = new Context(OperationMultiply.INSTANCE);    
      System.out.println("10 * 5 = " + context.executeStrategy(10, 5));
   }
}

这样，无论 main 方法被调用多少次，都只会创建三个策略对象，而不是每次调用都创建新对象。这种方法降低了对象创建和垃圾收集的开销，特别是在高并发环境下。

3 组合模式

设计模式之组合模式

3.1 组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对待单个对象或组合对象的使用具有一致性。如何理解这里的一致性？

组合模式中的“一致性”指的是单个对象（叶子对象）和组合对象（组合部分，即包含其他对象的对象）在客户端的使用方式上是相似或相同的。换句话说，客户端无需关心它正在处理的是单个对象还是组合的对象集合。

为了实现这种一致性，组合模式通常定义一个公共的接口或抽象类，这个接口或抽象类既适用于单一对象，也适用于组合对象。这样，无论客户端正在处理的是单一对象还是对象的组合，它都可以统一地引用这个公共接口或抽象类，从而达到一致性。

这种一致性带来的好处是：

1. 简化客户端代码：客户端代码可以统一地处理所有对象，不必区分它们是叶子对象还是组合对象。
2. 增强可扩展性：如果将来需要增加新的组件类型，只需使它们满足已定义的公共接口或抽象类即可。
3. 使层次结构更清晰：由于叶子和组合对象遵循相同的接口，组成的树形结构更为统一和清晰。

例如，考虑一个文件系统，其中存在文件和文件夹。文件是叶子对象，而文件夹是组合对象，因为它可以包含其他文件或文件夹。如果为这两者定义一个公共的接口，如FileSystemElement，并为其定义一些通用方法如getSize()或getName()，那么不论我们正在处理的是文件还是文件夹，对客户端代码来说，其处理方式都是一样的，这就是所说的“一致性”。

4 观察者模式

4.1 观察者模式的实现demo

观察者模式：https://www.runoob.com/design-pattern/observer-pattern.html

4.2 epoll中体现的观察者模式原理

在epoll中，可以将socket缓冲区看作是主题，而epoll线程（或epoll机制中用来监视事件的部分）作为观察者。

让我们再次澄清这个概念：

epoll与观察者模式的关系：

• 被观察对象 (Subject): 文件描述符相关的缓冲区、状态等。例如，一个TCP套接字的接收缓冲区。

• 观察者 (Observer): epoll机制。它注册了对特定文件描述符的关注，并等待这些文件描述符上的特定事件（如可读、可写等）。

当一个文件描述符变得可读或可写时（例如，因为有新数据到达了接收缓冲区），缓冲区/状态（作为被观察对象）发生了变化。epoll（作为观察者）会被通知这个变化，然后相应的处理代码就会被调用。

所以，你是对的，epoll更像是观察者，而文件描述符的状态和缓冲区才是被观察的对象。再次为之前的误解道歉，感谢你指出。

4.3 观察者模式在java中的哪些框架中得到了应用呢？

观察者模式是一个相当通用的设计模式，并在多种Java框架和库中得到了应用。以下是其中的一些示例：

1. JavaBeans: JavaBeans 使用属性更改监听器来通知其他对象属性的更改。这实质上是观察者模式的一个变种，其中属性更改监听器扮演观察者的角色，JavaBean 是被观察对象。

2. Swing: Swing GUI库中的大多数组件（如按钮、文本框等）都支持事件监听。当用户与这些组件交互（例如点击按钮）时，将触发事件，注册的监听器（观察者）将接收到通知。

3. JavaFX: 与Swing类似，JavaFX也使用了观察者模式来处理用户界面事件。例如，当用户与按钮或其他控件交互时，可以注册事件处理程序来响应。

4. RxJava: RxJava是一个响应式编程库，它在很大程度上建立在观察者模式之上。在这里，Observable对象表示一个数据流，Observer则订阅这个数据流并响应数据项、错误或流的完成。

5. Spring Framework: 在Spring中，可以使用@EventListener注解来监听和处理应用程序事件。这也是观察者模式的应用，其中事件发布者是被观察者，而使用@EventListener注解的方法是观察者。

6. Java 9的Flow API: Java 9引入了Flow API作为响应式流的一部分，其中Publisher代表数据源（被观察者），而Subscriber则代表数据消费者（观察者）。

这只是观察者模式在Java世界中应用的一些示例，实际上它在许多其他场景和库中也得到了广泛使用。

4.4 发布订阅机制是一种观察者模式的实现吗

是的，发布-订阅（Pub-Sub）机制是观察者模式的一种变种或特定实现。它们都涉及到一种“一对多”的依赖关系，其中多个对象依赖于一个对象的状态变化。当该对象状态发生变化时，依赖它的对象会被通知。

具体来说，两者之间的主要差异和特点如下：

1. 通信方式:

   • 观察者模式: 通常直接涉及到具体的观察者和被观察者对象。当被观察者的状态变化时，它直接通知注册的观察者。
   • 发布-订阅模式: 通常涉及到一个中间组件（经常是消息代理或事件总线），负责管理订阅和发布消息。发布者发布消息，但并不直接发送给订阅者。相反，发布的消息被放入一个中心位置，并由订阅者从那里获取或被动地接收。

2. 耦合:

   • 观察者模式: 被观察者通常需要知道其观察者的某些信息，这意味着它们之间存在直接的关联。
   • 发布-订阅模式: 由于存在中间组件，发布者和订阅者之间的耦合度较低，它们可能根本不知道彼此的存在。

3. 使用场景:

   • 观察者模式: 通常用于单一应用程序内的组件或对象之间的交互。
   • 发布-订阅模式: 经常用于分布式系统，其中生产者和消费者可能位于不同的系统或网络节点上。

4. 消息传递:

   • 观察者模式: 通常是同步的，即观察者响应状态的改变是即时的。
   • 发布-订阅模式: 可以是同步的也可以是异步的，取决于实现和配置。

总的来说，发布-订阅是观察者模式的扩展或特殊形式，具有更高的灵活性，尤其适用于大型、分布式系统。

5 单例

实现单例模式有好几种方案，其中双检锁是比较好的一种（懒加载+线程安全），可以参考这个链接看一看单例的具体实现: 单例模式

5.1 多例的并发性是否比单例好：

这并不是一个绝对的“是”或“否”的问题，因为它取决于具体的使用情况和对象的性质。

• 如果一个对象是无状态的（即它不持有任何可变的数据），那么无论是单例还是多例，其并发性能都会很好，因为多个线程可以无冲突地并发访问它。

• 如果对象持有可变状态，那么当多个线程尝试并发访问或修改这些状态时，你需要进行同步，这可能会导致性能下降。在这种情况下，使用多例可能会提高性能，因为每个线程或每个请求可以有自己的对象实例，从而减少了同步的需求。

总的来说，多例模式可能提供更好的并发性能，但这取决于具体的使用情况。

5.2 为什么 Controller 必须是单例的：

在许多现代的 Web 框架（例如 Spring）中，控制器 (Controller) 默认是单例的。这样做有以下几个理由：

• 性能：对于每次的 HTTP 请求都创建一个新的 Controller 实例会增加创建对象和垃圾回收的开销。由于 HTTP 请求通常是非常频繁的，因此这种开销可能会变得很大。

• 资源共享：Controller 可能需要访问如数据库连接、服务、配置等共享资源。将 Controller 设为单例可以更容易地管理和分享这些资源。

• 无状态性：为了使 Controller 能够安全地作为单例使用，通常建议它是无状态的。这意味着，所有与特定请求相关的状态都应存储在方法参数、局部变量或会话中，而不是在 Controller 的类级变量中。

但值得注意的是，并不是所有的框架或场景都要求 Controller 是单例的。确实有些框架或应用可能选择使用原型模式的 Controller，但这需要确保 Controller 是线程安全的，并可能需要额外的资源管理逻辑。

5.3 三种常见的单例模式（淘天一面）

菜鸟教程-单例模式

5.4 登记式/静态内部类实现单例

5.4.1 static final SingletonInner，这里为什么要加上final关键字？

public class SingletonInner {
    private static class SingletonHolder {
        private static final SingletonInner INSTANCE = new SingletonInner();
    }

    private SingletonInner() {
    }

    public static SingletonInner getInstance() {
        return SingletonHolder.INSTANCE;
    }

在Java中，final关键字用于声明一个常量。当一个变量被声明为final后，它的值就不能再被修改。在这个SingletonInner类的实现中，INSTANCE是一个final静态字段，这意味着它只能被初始化一次。

这里有几个理由为什么要使用final关键字：

1. 不可变性（Immutability）: 一旦INSTANCE变量被初始化，其引用就不能被改变。这有助于保证单例模式的一致性。

2. 线程安全（Thread Safety）: 在Java中，final字段在构造函数完成后，会立即被初始化。由于Java内存模型的规定，这将确保INSTANCE字段被安全地发布，所有线程都可以安全地访问它。

3. 明确意图（Clarity）: 使用final关键字也是一种代码约定，明确表示这个字段不应该被更改。

4. 编译时检查（Compile-Time Checking）: 如果你试图改变一个final字段的值，编译器会报错。

因此，使用final关键字是一种很好的实践，确保了单例实例的不可变性和线程安全性。

5.4.2 如果去掉这个final，可能会造成多线程访问SingleHolder.instance被实例化多次是嘛？

如果去掉final关键字，SingletonHolder.INSTANCE本身不会被实例化多次。这是因为这个实例是在静态内部类SingletonHolder中创建的，这个类只会在第一次被访问时加载，所以INSTANCE仍然只会被初始化一次。

然而，去掉final关键字会导致以下问题：

1. 可变性（Mutability）: 去掉final意味着INSTANCE的引用可以被改变，这破坏了单例模式的基本规则，即单一实例。

2. 线程安全（Thread Safety）: 虽然单例实例本身不会被重新创建，但是如果INSTANCE不是final，那么在多线程环境中，其他线程可能改变INSTANCE的引用，从而导致不可预见的结果。

3. 编程约束（Coding Discipline）: final关键字强制实施不可变性，它会在编译时告诉编译器和其他开发者这个字段不应该被改变。

4. 语义明确（Semantic Clarity）: final关键字明确表示这个字段是一个常量，不应该被改变。

所以，虽然去掉final关键字不会导致SingletonHolder.INSTANCE被实例化多次，但它会引入其他潜在问题。为了维持单例的不变性和线程安全性，最好是保留final关键字。

5.4.3 那下面这种饿汉式的单例，为什么没有加final？

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton (){}  
    public static Singleton getInstance() {  
    return instance;  
    }  
}

在这个饿汉式的单例模式实现中，即使没有使用 final 修饰 instance，该实例也只会被创建一次。这是因为 instance 是在类加载时就被初始化的，Java 的类加载机制确保了这个初始化过程是线程安全的。

然而，即使在这个场景中 final 关键字不是严格必需的，使用它仍然有好处：

1. 不可变性（Immutability）: 添加 final 会使得 instance 的引用不可改变，这是符合单例模式的原则的。

2. 语义明确（Semantic Clarity）: 使用 final 也使得代码的意图更加明确——这个变量是不应被更改的。

3. 编译时检查（Compile-Time Checking）: 如果不慎添加了改变 instance 的代码，使用 final 会让编译器立即报错，从而避免了潜在的错误。

所以，虽然不使用 final 在这个特定的例子中可能不会导致问题，但使用 final 通常是一个更安全和更明确的做法。

6 代理

6.1 两种代理区别，后面问了性能区别

首先，我们来概述下Java中的两种代理机制：静态代理和动态代理。

1. 静态代理：

   • 代理类和被代理类在编译期间就已经确定下来了。
   • 被代理类和代理类都需要实现相同的接口。
   • 如果接口中增加方法，那么代理类和被代理类都需要进行修改。

2. 动态代理：

   • 代理对象不需要实现接口，但是目标对象必须实现接口。
   • 代理对象是在运行时生成的。
   • Java的核心库提供了动态代理支持，包括java.lang.reflect.Proxy类和java.lang.reflect.InvocationHandler接口。

性能区别：

• 静态代理：因为它是在编译时已经确定的，所以没有反射机制的开销，通常认为性能较好。

• 动态代理：它在运行时通过反射生成代理对象，所以相对来说性能可能会稍差一些。但实际上，由于JVM的优化，这种差异通常是可以接受的。

6.2 静态代理

jdk动态代理随版本迭代做了什么优化

JDK动态代理是Java提供的反射功能的一部分。在其随着版本迭代的过程中，主要的优化是围绕反射性能的提升以及API的增强。但是，具体到动态代理的性能优化和API增强，官方文档和更新日志中往往没有深入到每一个细节。以下是反射和动态代理随JDK版本迭代中的一些相关的优化和变化：

1. JDK 7：

   • 此版本主要对Java的语言特性和JVM进行了优化，但没有特定于动态代理的重大改进。

2. JDK 8：

   • 引入了MethodHandles，这是一个性能更优的反射替代品。虽然这并不是直接影响Proxy类的，但它为高性能的代码生成和调用提供了更多的可能性。

3. JDK 9：

   • 介绍了模块系统，它有一些与反射和动态代理的互操作性的变化，特别是关于模块的可访问性。
   • 一些内部的优化可能有助于提高反射和动态代理的性能，但具体的优化并没有详细列出。

4. JDK 10 & 11：

   • 持续对JVM进行了优化，从而间接地提高了动态代理的性能。
   • 更好地支持了AOT（Ahead-of-Time Compilation），这可以为动态代理带来性能优化，因为代理类的生成和调用可以受益于AOT编译。

5. JDK 12 & 13：

   • 这两个版本主要是对Java语言和JVM的增强，没有针对动态代理的显著变化。

6. 后续版本：

   • 随着每一个新版本，都可能会有JVM级别的优化和改进，这些可能会影响动态代理的性能。

需要注意的是，JVM的每个新版本都可能包括对字节码生成、执行和优化的改进，这些都可能间接地影响动态代理的性能。但具体到动态代理的直接优化，这些可能并不总是在发布说明或官方文档中明确指出。

如果你对某个具体版本中的动态代理的优化特别感兴趣，可能需要查看具体的JDK发布日志、官方文档，或者直接深入到OpenJDK的源代码和社区讨论中去。