SupplierJwtDecoder延迟初始化的作用及委托模式延迟初始化的优势与问题

延迟初始化的核心优势 #

• 降低启动开销：JwtDecoder的初始化常涉及远程请求（比如拉取JWKS密钥集）或加密组件的复杂初始化，如果应用启动后短期内无需处理JWT校验请求，延迟初始化能避免这类不必要的资源消耗，让应用启动更快、占用资源更少。
• 适配动态配置场景：如果JwtDecoder的依赖项（比如JWKS端点地址、密钥信息）是运行时动态变更的，延迟初始化可以在首次解码时获取最新配置，避免启动阶段因配置未就绪或过期导致的初始化失败。
• 解耦初始化与解码逻辑：通过委托模式把初始化逻辑交给Supplier实现，SupplierJwtDecoder只专注于解码核心逻辑，初始化的细节（比如重试、配置刷新）可以在Supplier中独立维护，代码职责更清晰，扩展性更强。

同步问题的处理 #

你贴出的代码已经通过**双重检查锁定（Double-Checked Locking）**机制解决了多线程下的同步问题：

1. 外层的if (this.delegate == null)判断，避免每次调用decode都进入同步块，保证大部分场景下的调用性能不受影响；
2. 同步块内再次判断delegate是否为空，确保只有第一次调用时才会执行初始化逻辑，防止多线程环境下重复创建JwtDecoder实例；
3. 捕获初始化异常并包装为JwtException，保证初始化失败时能以统一的异常类型向外抛出。

需要注意的是，delegate字段需要被volatile修饰，否则可能因JVM指令重排序导致其他线程看到未完全初始化的实例，不过Spring官方实现的SupplierJwtDecoder已经处理了这个细节。

附上代码实现：

@Override
public Jwt decode(String token) throws JwtException {
    if (this.delegate == null) {
        synchronized (this.jwtDecoderSupplier) {
            if (this.delegate == null) {
                try {
                    this.delegate = this.jwtDecoderSupplier.get();
                } catch (Exception ex) {
                    throw wrapException(ex);
                }
            }
        }
    }
    return this.delegate.decode(token);
}

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