原型设计模式

原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式之一。

原型模式

实际使用就像是Java的克隆clone，以及spring的@Scope("prototype")。

实际使用中，比如异步导出。逻辑都很相似：查询数据、导出数据。

然后可以写一个AsyncExportTask，类上面使用@Scope("prototype")注解。使用时通过ApplicationContext来获取不同的原型bean即可。然后使用异步线程执行即可。

最典型的就是 "原型作用域（Prototype Scope）" 的 Bean 管理。下面用通俗的话讲清楚它在 Spring 中的具体用法、场景和原理：

Spring 中默认的 Bean 是 "单例（Singleton）" 的 ------ 容器启动时创建一次，之后所有地方用的都是同一个对象。但有些场景下，我们需要 "每次获取都新建一个对象"，而且这些对象的初始化逻辑相同（比如都需要加载相同的基础配置），这时候就可以用原型作用域，本质就是 Spring 帮我们实现了 "克隆式创建"。

举个例子：

假设我们有一个 UserService，里面需要初始化一些基础配置（比如数据库连接信息、日志工具），但每次调用时都需要一个新的实例（比如避免多线程共享状态导致的问题）。

定义原型 Bean：用 @Scope("prototype") 标注，告诉 Spring："这个 Bean 是原型的，每次获取都新创建一个"。

复制代码

@Service
@Scope("prototype") // 声明为原型作用域
public class UserService {
    private String dbUrl;
    private Logger logger;

    // 初始化方法：加载基础配置（只在创建时执行一次）
    @PostConstruct
    public void init() {
        this.dbUrl = "jdbc:mysql://localhost:3306/test"; // 基础配置
        this.logger = LoggerFactory.getLogger(UserService.class);
        System.out.println("初始化基础配置完成");
    }

    public void doSomething() {
        logger.info("执行操作，使用数据库：" + dbUrl);
    }
}

使用原型 Bean：每次从 Spring 容器中获取 UserService 时，都会得到一个新的实例，但每个实例的 dbUrl、logger 等基础配置都是通过 init 方法初始化好的（相当于克隆了 "基础配置模板"）。

复制代码

@Component
public class UserController {
    @Autowired
    private ApplicationContext context;

    public void test() {
        // 第一次获取：新建一个 UserService 实例，执行 init
        UserService service1 = context.getBean(UserService.class);
        // 第二次获取：再新建一个 UserService 实例，执行 init
        UserService service2 = context.getBean(UserService.class);

        // service1 和 service2 是不同的对象，但基础配置相同
        System.out.println(service1 == service2); // 输出：false
    }
}

二、为什么这是原型模式？

原型模式的核心是 "基于已有模板克隆新对象"，而 Spring 原型作用域的逻辑完全符合：

"模板"：就是 UserService 的类定义 + @PostConstruct 初始化的基础配置（相当于原型对象）。

"克隆"：Spring 每次获取原型 Bean 时，都会通过反射创建一个新实例，并执行初始化方法（相当于 "克隆" 模板的基础配置），避免了手动重复写初始化代码。

"灵活微调"：如果需要对新对象做个性化修改（比如给某个 UserService 实例改 dbUrl），直接修改新对象即可，不影响其他实例和 "模板"。

三、适合用原型作用域的场景（原型模式思想）

多线程场景：避免状态共享如果 Bean 里有 "状态"（比如成员变量存储临时数据），单例模式下多线程并发访问可能导致数据混乱。用原型模式（原型作用域），每个线程拿到自己的实例，互不干扰。比如：OrderProcessor 处理订单时需要临时存储订单 ID，多线程同时处理时，每个线程用自己的 OrderProcessor 实例，避免订单 ID 串错。
对象创建成本高：复用初始化逻辑如果 Bean 的初始化步骤复杂（比如加载配置文件、连接数据库、初始化缓存），每次手动 new 对象并重复初始化代码很麻烦。用原型作用域，Spring 会自动执行初始化逻辑，新对象直接复用这些基础配置。比如：ReportGenerator 需要加载报表模板、设置字体样式等初始化操作，原型模式让每次创建的实例都自带这些配置，不用重复写。
临时对象：用完即弃有些对象只是临时用一次（比如处理单次请求的上下文对象 RequestContext），不需要单例复用，用原型模式创建更合适，避免单例占用内存。

四、Spring 原型模式的注意点

和单例 Bean 搭配时要小心如果单例 Bean 依赖了原型 Bean（比如单例 UserController 里注入原型 UserService），默认情况下，Spring 只会在单例初始化时获取一次原型 Bean，之后一直用同一个，不会自动刷新。

解决办法：每次需要时通过 ApplicationContext 手动获取原型 Bean，或者用 ObjectProvider 延迟获取。

原型 Bean 的生命周期自己管，单例 Bean 由 Spring 全程管理（从创建到销毁），但原型 Bean 一旦被创建并交给用户，Spring 就不再管了（不会自动调用 @PreDestroy 销毁方法），需要自己处理资源释放。

原型对比工厂

若新对象和某个已有对象高度相似，只是微调细节，且创建这个对象很麻烦 ------ 用原型模式（复制比新建省事）；

若要创建的对象有多种类型，每种类型有固定的创建规则，但没有现成的 "模板对象"------ 用工厂模式（按规则造比维护多个原型省心）。

原型对比享元

原型侧重高效创建复杂对象，减少重复的初始化代码------多个相似复杂对象

享元侧重复用对象减少实例数量，降低内存占用------大量相似的简单对象