本文探讨了在Spring应用中如何高效地定时刷新共享资源（如安全令牌），避免每次请求都执行昂贵的创建操作。我们将介绍几种实现策略，包括使用独立的令牌持有者Bean、直接更新Spring上下文，以及推荐的将刷新逻辑集成到资源提供者自身的方案，并通过代码示例详细说明其实现方式和最佳实践。
在现代微服务架构或需要与外部系统交互的应用中，经常会遇到需要获取并使用短期有效凭证（如OAuth2令牌、API密钥）的场景。这些凭证通常有生命周期限制，需要在过期前进行刷新。然而，每次请求都重新生成这些凭证可能是昂贵且低效的。一个常见的需求是，在凭证过期前（例如，有效期5分钟，但在4分钟时刷新），通过定时任务机制自动更新它，并确保应用中的其他组件能够持续使用最新的有效凭证。
Spring框架提供了强大的调度能力（@Scheduled），但其与Bean的结合使用存在一些限制。例如，@Scheduled注解的方法通常要求返回类型为void，这意味着不能直接通过 @Scheduled 方法返回一个Bean实例。本文将详细探讨几种解决方案，以实现在Spring中定时刷新共享资源。
1. 问题场景与初始尝试
假设我们有一个 Authorization 服务，它提供一个 getToken() 方法来生成安全令牌，该令牌有效期为5分钟。我们希望每4分钟刷新一次这个令牌，并将其注入到需要使用它的 Manager 组件中。
最初的尝试可能如下：
@Configuration@EnableSchedulingpublic class Config { private final Authorization authorization; public Config(Authorization authorization) { this.authorization = authorization; } // 无法直接这样使用：@Scheduled 方法需要返回 void // @Scheduled(fixedDelayString = "${fixed.delay:PT4M}") // @Bean // public String getToken() { // return authorization.getToken(); // }}
以及使用令牌的 Manager 组件：
@Componentpublic class Manager { private final String path; private final String token; // 期望从上述Bean中获取 private final RestOperations restOperations; public Manager( @Value("${my.path}") String path, String token, // 注入令牌 RestOperations restOperations) { this.path = path; this.token = token; this.restOperations = restOperations; } public Object restCall() { // 使用 token 进行 REST 调用 // ... return null; }}
如代码注释所示，这种直接将 @Scheduled 与 @Bean 结合的方式是不可行的，因为 @Scheduled 方法的返回类型必须是 void。我们需要一种机制来存储和更新这个定时刷新的令牌。
2. 解决方案一：使用独立的令牌持有者Bean
一种直接且相对简单的解决方案是引入一个专门的Bean来持有并提供这个定时刷新的令牌。这个Bean可以是单例的，其内部的令牌值通过 @Scheduled 方法进行更新。
2.1 实现方式
首先，创建一个简单的类作为令牌持有者。
@Componentpublic class TokenHolder { private volatile String token; // 使用 volatile 确保可见性 public String getToken() { return token; } public void setToken(String token) { this.token = token; }}
然后，在配置类中，使用 @Scheduled 方法定期调用 Authorization 服务获取新令牌，并更新 TokenHolder。
Pic Copilot
AI时代的顶级电商设计师，轻松打造爆款产品图片
158 查看详情 
@Configuration@EnableSchedulingpublic class AuthSchedulerConfig { private final Authorization authorization; private final TokenHolder tokenHolder; public AuthSchedulerConfig(Authorization authorization, TokenHolder tokenHolder) { this.authorization = authorization; this.tokenHolder = tokenHolder; } @Scheduled(fixedDelayString = "${fixed.delay:PT4M}") public void updateTokenSchedule() { String newToken = authorization.getToken(); tokenHolder.setToken(newToken); System.out.println("Token refreshed at " + System.currentTimeMillis() + ": " + newToken); } // 应用启动时立即获取一次令牌 @PostConstruct public void initializeToken() { updateTokenSchedule(); }}
现在，Manager 组件不再直接注入 String 类型的令牌，而是注入 TokenHolder，并在需要时通过 tokenHolder.getToken() 获取最新令牌。
@Componentpublic class Manager { private final String path; private final TokenHolder tokenHolder; // 注入令牌持有者 private final RestOperations restOperations; public Manager( @Value("${my.path}") String path, TokenHolder tokenHolder, RestOperations restOperations) { this.path = path; this.tokenHolder = tokenHolder; this.restOperations = restOperations; } public Object restCall() { String currentToken = tokenHolder.getToken(); // 每次调用时获取最新令牌 // 使用 currentToken 进行 REST 调用 System.out.println("Manager using token: " + currentToken); return null; }}
2.2 优点与注意事项
优点：实现简单直观，将令牌的存储与刷新逻辑分离。注意事项：TokenHolder 中的 token 字段使用 volatile 关键字，以确保在多线程环境下，getToken() 总是能读取到 setToken() 写入的最新值。需要在应用启动时手动调用一次 updateTokenSchedule() 或在 TokenHolder 中初始化令牌，以确保在第一次定时任务执行前就有可用的令牌。
3. 解决方案二：直接更新Spring上下文中的Bean（不推荐）
虽然技术上可行，但这种方法通常不被推荐，因为它直接操作Spring应用上下文，增加了系统的复杂性和耦合度。它通过 GenericApplicationContext 动态注册或替换Bean。
@Configuration@EnableSchedulingpublic class AuthSchedulerContextConfig { @Autowired private GenericApplicationContext context; // 注入应用上下文 private final Authorization authorization; public AuthSchedulerContextConfig(Authorization authorization) { this.authorization = authorization; } @Scheduled(fixedDelayString = "${fixed.delay:PT4M}") public void updateTokenInContext() { String newToken = authorization.getToken(); // 动态注册或替换名为 "token" 的 String 类型 Bean context.registerBean("token", String.class, () -> newToken); System.out.println("Token in context refreshed at " + System.currentTimeMillis() + ": " + newToken); } @PostConstruct public void initializeTokenInContext() { updateTokenInContext(); }}
在这种情况下，Manager 组件可以像最初设想的那样直接注入 String 类型的令牌。
@Componentpublic class Manager { // ... (其他字段和构造器) private final String token; // 直接注入 String 类型的 token public Manager( @Value("${my.path}") String path, String token, // Spring 会从上下文获取名为 "token" 的 String Bean RestOperations restOperations) { this.path = path; this.token = token; this.restOperations = restOperations; } public Object restCall() { // 注意：这里注入的 token 是在 Manager 初始化时上下文中的值。 // 如果 Manager 是单例的，它不会自动获取到后续定时刷新的 token。 // 除非 Manager 每次使用时都从 ApplicationContext 重新获取，但这会更复杂。 System.out.println("Manager using token (potentially stale if not prototype): " + token); return null; }}
3.1 缺点与限制
复杂性高：直接操作 ApplicationContext 增加了代码的复杂性。Bean作用域问题：如果 Manager 是单例的（默认），它在初始化时注入的 token 值将不会随上下文中的 token Bean 刷新而自动更新。要解决这个问题，Manager 需要是原型（@Scope(“prototype”)）Bean，或者每次使用时都从 ApplicationContext 中获取 token，这又增加了复杂性。
鉴于上述缺点，此方法通常不作为首选。
4. 解决方案三：将刷新逻辑集成到资源提供者自身（推荐）
这种方法被认为是最佳实践，因为它将令牌的获取、存储和刷新逻辑封装在 Authorization 服务内部，使得 Authorization 服务成为一个自给自足的令牌提供者。其他组件只需注入 Authorization 服务，并通过其方法获取最新令牌，而无需关心令牌的刷新机制。
4.1 实现方式
首先，重构 Authorization 类，使其内部维护令牌状态，并提供刷新和获取令牌的方法。
@Componentpublic class Authorization { private volatile String currentToken; // 内部维护令牌，使用 volatile 确保可见性 // 模拟获取新令牌的耗时操作 public String generateNewToken() { System.out.println("Generating new token..."); try { Thread.sleep(500); // 模拟网络延迟或计算开销 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return "new-security-token-" + System.currentTimeMillis(); } // 用于定时任务调用的方法，更新内部令牌 public void updateToken() { this.currentToken = generateNewToken(); System.out.println("Authorization service updated token: " + currentToken); } // 提供给外部组件获取令牌的方法 public String getToken() { if (this.currentToken == null) { // 第一次获取时进行初始化 updateToken(); } return this.currentToken; } @PostConstruct public void initializeToken() { updateToken(); // 应用启动时立即初始化令牌 }}
然后，在配置类中，创建一个简单的 @Scheduled 方法，定期调用 Authorization 服务的 updateToken() 方法。
@Configuration@EnableSchedulingpublic class AuthSchedulerConfig { private final Authorization authorization; public AuthSchedulerConfig(Authorization authorization) { this.authorization = authorization; } @Scheduled(fixedDelayString = "${fixed.delay:PT4M}") public void refreshAuthorizationToken() { authorization.updateToken(); // 定时调用 Authorization 服务刷新令牌 }}
现在，Manager 组件只需注入 Authorization 服务，并在需要时调用 authorization.getToken()。
@Componentpublic class Manager { private final String path; private final Authorization authorization; // 注入 Authorization 服务 private final RestOperations restOperations; public Manager( @Value("${my.path}") String path, Authorization authorization, RestOperations restOperations) { this.path = path; this.authorization = authorization; this.restOperations = restOperations; } public Object restCall() { String currentToken = authorization.getToken(); // 每次调用时从 Authorization 服务获取最新令牌 // 使用 currentToken 进行 REST 调用 System.out.println("Manager using token from Authorization service: " + currentToken); return null; }}
4.2 优点与注意事项
优点：高内聚：令牌的生成、存储和刷新逻辑全部封装在 Authorization 服务内部，符合单一职责原则。低耦合：其他组件只需依赖 Authorization 接口或类，无需关心令牌是如何刷新或存储的。易于测试：Authorization 服务可以独立测试其令牌管理逻辑。线程安全：通过 volatile 关键字确保 currentToken 的可见性，并且 getToken() 每次都返回最新值。注意事项：确保 Authorization Bean 是单例的（Spring 默认就是单例），这样所有注入它的地方都引用同一个实例。考虑令牌刷新失败的场景。在 updateToken() 方法中应该加入适当的错误处理和重试机制，以防令牌生成失败导致旧令牌过期而新令牌未成功获取。fixedDelayString 的配置应考虑令牌的实际有效期和刷新所需时间，确保在令牌过期前有足够的时间完成刷新。例如，如果令牌有效期是5分钟，刷新任务应在4分钟左右触发。
总结
在Spring应用中定时刷新共享资源，最推荐的方式是将资源的持有和刷新逻辑封装到资源提供者自身。这种方法（解决方案三）提供了最佳的内聚性和解耦性，使得系统设计更加清晰和健壮。通过 @Scheduled 注解配合 volatile 关键字和 Authorization 服务内部的令牌管理，可以高效且安全地实现定时刷新共享资源的需求。避免直接操作Spring上下文来动态替换Bean，因为它可能引入不必要的复杂性和Bean作用域问题。
以上就是如何在Spring中定时刷新Bean或共享资源的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1064062.html
微信扫一扫 
支付宝扫一扫 
