将Spring ApplicationContext存入请求关联ThreadLocal是否安全？含JPA PrePersist场景

让我分两部分拆解你的问题，都是日常开发中很常见的场景，结合Spring和JPA的特性给你分析：

首先明确：ApplicationContext本身是线程安全的——Spring容器初始化完成后就处于只读状态，单例Bean的实例化、依赖注入都是在启动阶段完成的，后续不会有修改容器结构的操作。所以把它放到ThreadLocal里这个行为本身，只要你能保证ThreadLocal的清理时机绝对正确，就不会有线程安全问题。

但这里有两个必须重视的坑要提醒你：

• 一定要在请求结束时手动移除ThreadLocal中的上下文引用，比如在自定义Filter的doFilter方法的finally块里调用threadLocal.remove()，或者用Spring的@AfterCompletion注解处理。如果不清理，当线程被Tomcat等Web容器的线程池复用后，上一个请求的上下文会被带到下一个请求里，不仅可能导致业务逻辑错误，还会引发内存泄漏（ThreadLocal的Entry是弱引用，但线程存活时，Value的强引用不会被GC回收）。
• 其实Spring本身已经提供了更优雅的获取ApplicationContext的方式：比如让Bean实现ApplicationContextAware接口，或者直接用@Autowired注入ApplicationContext。除非你是在无法依赖注入的环境（比如JPA实体类，因为实体不是Spring管理的Bean），否则完全没必要自己手动维护ThreadLocal。

你的需求很清晰：在PrePersist方法里调用Spring管理的Support类，但不想让Support成为单例，所以想用ThreadLocal传上下文拿Bean。结合这个场景，我可以明确说：只要做好ThreadLocal的清理，这个操作是安全的，理由如下：

• 你只是调用getBean(Support.class)，并且不对ApplicationContext做任何修改——如前所述，ApplicationContext是只读的线程安全容器，读取操作完全没问题。
• 如果Support是原型（prototype）作用域的Bean，每次getBean都会返回新实例，完美符合你不想让它单例的需求，而且Spring创建原型Bean的过程本身是线程安全的。

但还有几个关键细节要注意：

• ThreadLocal的初始化时机要准确：要在请求开始时（比如Filter拦截到请求的第一时间）就把ApplicationContext存入ThreadLocal，确保每个请求对应的线程都能拿到正确的上下文。Web应用里每个请求对应独立线程（线程池复用但清理ThreadLocal的话不影响），所以只要初始化时机没问题就ok。
• 清理操作不能忘：这是重中之重，哪怕代码里其他逻辑都对，忘记清理ThreadLocal一定会出问题。建议用Filter来统一处理：在Spring的RequestContextFilter之后加一个自定义Filter，在doFilter的finally块里执行清理。
• 可以考虑更优雅的替代方案：比如写一个单例的ApplicationContextProvider（实现ApplicationContextAware接口，持有ApplicationContext引用），然后在PrePersist方法里直接调用这个Provider的getBean方法。你担心的“单例依赖”其实没问题——这个Provider只是个无状态的工具类，本身不保存业务数据，只是帮你拿Bean；而Support如果是原型作用域，每次调用还是新实例，完全满足你的需求。不过如果你坚持不想用单例Provider，ThreadLocal的方式是可行的，但清理一定要做足。

内容的提问来源于stack exchange，提问作者Archimedes Trajano