在Java后端开发的江湖里Spring框架几乎就是“标准配置”的代名词。咱们每天dou在和Bean打交道，但你是否停下来思考过这样一个kan似简单却暗藏玄机的问题：这个Bean，到底该活多久？

hen多写了三五年Spring代码的同行，可Neng从未显式地在代码里指定过scope。面试的时候，大家douNeng流利地背出“单例、原型、请求、会话”这几个词，仿佛这就是全部的真相。然而真正的技术功底不在于背诵八股文，而在于理解框架设计背后的权衡。Spring为什么要搞出这么多种作用域？它们分别是为了解决什么具体的痛点？

今天咱们不念文档，而是像架构师一样思考，深入剖析Spring Bean作用域的设计逻辑，以及在实际项目中如何Zuo出Zui明智的选择。

一、 核心判断逻辑：共享还是隔离？

面对复杂的业务需求，我们在选择Bean作用域时其实只需要回答三个灵魂拷问：

这个Bean需不需要在多个地方共享实例？

Ru果需要共享，这个共享的范围是多大？

它的生命周期应该跟随谁？容器？请求？还是用户？

想清楚了这三点，Spring那六种作用域的定位自然就清晰了。这不仅仅是配置问题，geng是对系统状态管理策略的顶层设计。

二、 默认的王者：Singleton

咱们平心而论，在真实的业务代码里出镜率Zui高的永远只有那一位——Singleton。无论是Service层、Repository层还是Controller层，只要不加注解指定，Spring默认统统按照单例来处理。

为什么Rod Johnson当初会如此坚定地选择它作为默认值？原因hen简单：效率。

绝大多数业务对象dou是“无状态”的。它们就像纯函数，接收参数，处理逻辑，吐出结果，不在对象内部保存请求间的数据。对于这类对象，整个JVM里维护一个实例就足够应付所有并发请求了。复用同一个实例，不仅避免了频繁创建销毁对象带来的CPU开销，大大减轻了GC的压力，而且依赖注入的初始化流程只需要执行一次。

源码背后的缓存机制

翻kanSpring的源码，在`AbstractBeanFactory`的`doGetBean`方法里你会kan到针对单例的专门处理分支。核心逻辑在于一个缓存映射，它定义在`DefaultSingletonBeanRegistry`中：

// 这是一个典型的ConcurrentHashMap，以bean名称为Key，实例为Value
private final Map singletonObjects = new ConcurrentHashMap<>;

当容器需要一个单例Bean时它先去这个Map里找。找到了？直接返回。没找到？那就通过回调机制创建一个，放进去，然后再返回。这种“缓存优先”的策略，是Spring高性Neng运行的基石之一。

澄清一个常见的误区

这里必须得敲黑板划重点：Spring的Singleton和设计模式教科书里的“单例模式”完全是两码事。

GoF里的单例模式，是指在一个ClassLoader下一个类只Neng有一个实例。而Spring的单例，是“容器级别”的概念。同一个类，你Ke以在Spring容器里注册多个Bean定义，每个定义在容器里各自dou有一个独立的实例。它本质上是一种容器层面的缓存策略，而不是硬性的类级别实例化限制。理解了这一点，你就不会再被面试官问倒了。

三、 状态隔离的利器：Prototype

虽然Singleton包打天下但总有那么一些场景，它搞不定。Zui典型的就是有状态对象。

想象一下你正在写一个复杂的报表生成器。这个生成器需要在对象内部记录当前处理到哪一行了、累计的统计值是多少。Ru果把这个生成器设为Singleton，两个线程同时进来生成不同的报表，它们操作的是同一个内存对象！线程A的数据会被线程B覆盖，或者反过来。这种Bug在单线程测试时根本发现不了一上高并发环境，立马炸雷。

这时候，Prototype作用域就闪亮登场了。标记为prototype的Bean，每次向容器索取时容器dou会给你`new`一个全新的对象。

Prototype的“冷酷”一面

在源码层面Prototype的处理非常简单粗暴：没有任何缓存逻辑，每次dou走`createBean`。但这里有一个非常容易被新手忽略，甚至被老手遗忘的特性：Spring不负责销毁Prototype Bean。

在`AbstractBeanFactory`的销毁逻辑里有一行判断直接把Prototype给拒之门外：`if ...)`。这意味着，哪怕你在Prototype Bean里写了`@PreDestroy`回调，Spring也根本不会调用它。

这可不是Spring的Bug，而是有意为之的“甩锅”。容器根本不知道你创建出来的这个Prototype实例被谁拿走了是传给了哪个方法，还是塞进了哪个List。Ru果容器非要强管，为了调用销毁回调而一直持有所有Prototype实例的引用，那结果就是灾难性的——内存泄漏。所以Prototype Bean的生命周期是“管生不管养”，清理工作必须由调用方自己负责。

Ru果你的Prototype Bean里持有数据库连接、文件句柄这类稀缺资源，用完之后千万记得手动关闭，别指望容器帮你擦屁股。

四、 那个经典的“注入陷阱”与三种解法

理解了Prototype，hen多开发者会信心满满地去实践，结果往往踩进同一个坑里。

场景是这样的：你定义了一个Prototype的Bean，然后通过`@Autowired`把它注入到了一个Singleton的Controller里。你心想：“这下好了每次请求进来Controllerdou会拿到一个新的Processor。”

现实却是残酷的。因为Controller是Singleton的，它只在容器启动时初始化一次。那次初始化时Spring注入了一个Processor实例。之后无论来多少个请求，用的dou是那个“陈年老”实例。Prototype的作用域在这里完全失效了。

怎么破？这里有三种经典的解决方案，每种dou各有千秋。

1. 灵活的ObjectProvider

这是Spring 4.3引入的一个神器。你不直接注入Bean，而是注入一个“Bean的提供者”。

@RestController
public class OrderController {
    @Autowired
    private ObjectProvider processorProvider;
    @PostMapping
    public void handle {
        // 每次调用getObject，容器才会去创建新实例
        OrderProcessor processor = processorProvider.getObject;
        processor.process;
    }
}

这种方式侵入性极小，代码意图也hen清晰，是目前Zui推荐的写法。

2. 神奇的@Lookup注解

Ru果你不想在代码里显式依赖Spring的API，Ke以用`@Lookup`。把它标在一个方法上，Spring会通过CGLIB字节码增强技术，生成一个子类并覆盖这个方法。

@Component
public class OrderController {
    @Lookup
    protected OrderProcessor createProcessor {
        // 这里的返回值其实不重要，Spring会覆盖掉这个方法体
        return null;
    }
    public void handle {
        createProcessor.process;
    }
}

每次调用`createProcessor`，实际上dou是在委托给BeanFactory去获取一个新的实例。不过要注意，类不Neng是`final`的，否则CGLIB无法生成子类。

3. 透明的Scoped Proxy

第三种方法是对调用方完全无感的。在定义Bean的时候，加上`proxyMode`。

@Component
@Scope
public class OrderProcessor {}

这样，Spring注入到Controller里的其实是一个代理对象。这个代理对象本身是Singleton的，但当你调用它的方法时代理会智Neng地去当前的Scope里捞一个真实的Target实例给你。在Web作用域中，这种模式非常常见。

五、 Web环境专属：Request、Session与Application

Singleton和Prototype解决了“全局共享”和“绝不共享”的两个极端。但在Web开发中，我们geng多时候需要的是“中间状态”：同一个HTTP请求内的多个组件要共享数据，但不同请求之间要隔离；同一个用户的多次请求要共享状态，但不同用户之间要隔离。

Spring 2.0引入了Scope SPI，让Web作用域的注册变得非常灵活。只有在WebApplicationContext中，以下三种作用域才会生效。

Request：请求级的短命鬼

Request作用域把Bean的生命周期绑定到了单个HTTP请求上。请求来了Bean创建；请求结束，Bean销毁。底层实现上，它是把Bean存到了`HttpServletRequest`的Attribute里。

这非常适合Zuo请求级别的审计日志收集器，或者在请求处理过程中需要传递一些复杂上下文的场景。Spring提供了`@RequestScope`注解，它默认就开启了CGLIB代理，就是为了方便注入到Singleton的Controller中。

Session：用户级的私人保险箱

Session作用域的生命周期跟随HTTP Session。典型应用就是购物车、用户偏好设置。

这里有个hen有意思的细节：`SessionScope`的`get`方法是加了`synchronized`锁的。为什么？因为同一个用户可Neng并发发起多个请求，这些请求在服务端由不同线程处理，但它们操作的是同一个Session。Ru果不加锁，可Neng两个线程同时发现Bean不存在结果创建了两个实例，导致状态混乱。而`RequestScope`就不需要这个锁，因为一个请求通常只在一个线程内处理。

不过Session作用域用得越来越少了。大家geng倾向于把会话状态放到Redis里保持服务端的完全无状态。

Application：比Singletongeng“全局”的存在

Application作用域绑定到`ServletContext`。hen多人会问：这和Singleton有什么区别？

在Spring Boot这种单容器应用里两者确实几乎没区别。但在传统的Spring MVC架构中，Ru果有父子容器，Singleton Bean在父子容器里是各自一份的，而Application Bean在整个ServletContext里只有一份。它geng像是一种全局的静态变量。

六、 进阶玩法：自定义作用域

Spring的 性从来不会让人失望。除了内置的这几种，我们完全Ke以利用Scope SPI来实现自己的作用域。

比如你Ke以实现一个`SimpleThreadScope`，让Bean的生命周期跟随当前线程；或者实现一个`SimpleTransactionScope`，让Bean在同一个事务内共享。Spring其实Yi经提供了这些实现，只是默认没有注册，需要你手动开启。

要实现自定义Scope，你需要实现`Scope`接口，核心在于实现`get`、`remove`和`registerDestructionCallback`这几个方法。然后通过`ConfigurableBeanFactory.registerScope`把它注册进去。这属于高级玩家范畴，但在处理一些特定领域的遗留系统对接时往往Neng发挥奇效。

七、 ：架构师的决策清单

聊了这么多，Zui后咱们回到Zui初的问题：到底该怎么选？

这里给一份务实的决策指南：

默认首选Singleton： 99%的Service、Dao、Controllerdou是无状态的，不要犹豫，直接用默认的。这是性NengZui优解。

警惕有状态Bean： Ru果你的Bean需要在成员变量里存数据，先停下来思考：这个状态Neng不Neng移到方法参数里？Neng不Neng用ThreadLocal？Ru果Neng，就不要用Prototype。

Prototype是双刃剑： 只有在确实需要Spring帮你管理依赖注入、AOP代理，且每次dou需要新实例时才用。记得解决“注入Singleton”的问题，并手动处理资源释放。

Web作用域按需取用： Request适合请求级的数据传递；Session适合传统的单体应用用户状态；Application基本hen少用。

Spring的作用域设计经历了一个从“硬编码”到“高度可 ”的演进过程。从1.0版本只支持Singleton和Prototype，到2.0引入Scope SPI，体现了框架设计者“核心极简，边缘开放”的智慧。

选错了作用域，代码可Neng编译通过测试通过但在高并发上线的那一刻出现诡异的数据错乱。那时候再去排查，成本可是指数级上升。所以下次在写`@Component`的时候，多花一秒钟想想它的生命周期，你的代码质量会因此提升一个台阶。

希望这篇深入浅出的分析，Neng让你对Spring Bean的作用域有全新的认识。技术之路，道阻且长，与君共勉。

---