【Spring 2】深入剖析 Spring 的 Singleton 作用域：不仅仅是单例

原创于 2025-10-07 20:16:18 发布 · 839 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#spring #单例模式 #java

Spring 专栏收录该内容

3 篇文章

订阅专栏

在 Spring Framework 的浩瀚宇宙中，Bean 无疑是构成应用程序的基石。而当你定义 Bean 时，scope 属性是你必须理解的核心概念之一。其中，singleton 是默认的，也是最常用的作用域。但你真的了解它吗？今天，我们将拨开迷雾，深入探讨 Spring 中的 singleton，揭示其背后的原理、最佳实践以及需要警惕的陷阱。

1. 什么是 Singleton？一个被“误解”的老朋友

在谈论 Spring 之前，我们先回顾一下单例模式。在经典的设计模式中，单例模式确保一个类在 JVM 中只存在一个实例，并提供一个全局访问点。

然而，Spring 的 singleton 与经典的单例模式有所不同。

经典单例：其范围是 JVM 和 类加载器。它通过静态方法保证一个类加载器内只有一个实例。
Spring Singleton：其范围是 Spring IoC 容器。这意味着，对于一个特定的 Spring 容器（通常是 ApplicationContext），一个 Bean ID 只对应一个实例。

关键区别：如果你的应用有多个 Spring 容器（虽然不常见），那么每个容器都会创建自己的“单例”实例。因此，更准确地说，Spring Singleton 是 “每个容器 per bean id” 的单例。

2. 如何配置 Singleton Scope？（实战演示）

singleton 是默认作用域，所以你通常不需要显式指定。但显式声明是一个好习惯，它能让你的意图更加清晰。

2.1 XML 配置方式

<bean id="userService" class="com.example.UserServiceImpl" scope="singleton"/>
<!-- 等同于 -->
<bean id="userService" class="com.example.UserServiceImpl"/>

2.2 Java 注解方式

使用 @Scope 注解或直接使用 @Component（默认就是 singleton）。

@Component // 默认就是 singleton
// @Scope("singleton") // 这样写效果相同，但冗余
public class UserService {
    // ...
}

2.3 Java Config 方式

在 @Bean 方法上使用 @Scope。

@Configuration
public class AppConfig {

    @Bean
    @Scope("singleton") // 显式声明，可省略
    public UserService userService() {
        return new UserService();
    }
}

3. Singleton 的生命周期：一场精心编排的戏剧

理解 Singleton Bean 的生命周期至关重要。它与 Spring 容器紧密绑定：

实例化：容器启动时，所有非懒加载的 Singleton Bean 会立即被创建（遵循依赖关系）。
依赖注入：Spring 填充 Bean 的属性和其他依赖。
初始化：如果配置了 init-method 或 @PostConstruct 方法，它将被调用。
存活期：Bean 一直存在于容器中，服务于所有请求。它的状态可以被改变。
销毁：当容器关闭时（例如，在 Web 应用中关闭 ContextLoaderListener），如果配置了 destroy-method 或 @PreDestroy 方法，它将被调用。

重要特性：延迟初始化（Lazy）
默认情况下，Singleton Bean 是“急切”创建的。但你可以通过 @Lazy 注解或 lazy-init="true" 将其设置为延迟初始化。

@Component
@Lazy
public class HeavyResourceService {
    // 这个 Bean 只有在第一次被请求时才会创建
}

这在初始化非常耗时或资源消耗大的 Bean 时非常有用，可以加速应用的启动速度。

4. Singleton 的陷阱与最佳实践

Singleton 虽好，但若使用不当，会带来严重的后果。

4.1 陷阱1：状态问题（重中之重！）

问题描述：Singleton Bean 在内存中只有一份实例。如果它拥有可变的成员变量（状态），并且多个线程同时修改它，就会引发线程安全问题。

反面教材：

@Component
public class StatefulService {
    private int count; // 可变状态！

    public void increment() {
        count++; // 非原子操作，线程不安全！
    }

    public int getCount() {
        return count;
    }
}

如果两个线程同时调用 increment()，count 的最终值将无法预测。

解决方案：

方案A：无状态化（首选）
尽量将 Bean 设计为无状态的。这是最安全、最优雅的方式。

@Component
public class StatelessService {
    // 不持有可变状态，只提供服务方法
    public String process(String input) {
        return input.toUpperCase();
    }
}

方案B：使用 ThreadLocal
如果状态必须与线程绑定，可以使用 ThreadLocal。
方案C：使用同步机制
使用 synchronized、ReentrantLock 或 Atomic 类。但这会增加代码复杂性和影响性能。

4.2 陷阱2：循环依赖

由于 Singleton Bean 在容器启动时就创建，如果 Bean A 依赖 Bean B，同时 Bean B 也依赖 Bean A，就会形成循环依赖。

Spring 如何解决？
Spring 使用三级缓存机制，通过提前暴露一个“早期引用”来解决Setter注入/字段注入的循环依赖。但对于构造器注入的循环依赖，Spring 无法解决，会在启动时抛出 BeanCurrentlyInCreationException。

最佳实践：尽可能使用 Setter 注入而非构造器注入，或者重新设计代码结构，避免循环依赖。

4.3 陷阱3：资源消耗

如果一个 Singleton Bean 非常庞大且不常用，在启动时就创建它会浪费内存和启动时间。此时，应考虑使用 @Lazy 进行延迟加载。

5. Singleton vs. Prototype：何时用谁？

特性	Singleton	Prototype
实例数量	每个容器一个	每次请求一个新实例
创建时机	容器启动时（默认）	每次注入或 `getBean()` 时
内存占用	低	高（可能）
性能	高（无需频繁创建）	低（创建销毁开销）
状态	需谨慎处理，推荐无状态	天然线程安全，可有状态
适用场景	无状态的工具类、服务层、数据访问层	有状态的会话处理、需要隔离的上下文