Quarkus Amazon Lambda中如何注入com.amazonaws.services.lambda.runtime.Context

我在Quarkus Amazon Lambda应用中，希望将com.amazonaws.services.lambda.runtime.Context作为可注入Bean访问，用来获取AwsRequestId或剩余执行时间这类信息。

目前我采用的实现方式如下：

public interface ContextHolder {
    Context getContext();
}

@ApplicationScoped
public class Lambda implements RequestHandler<SQSEvent, SQSBatchResponse> {

    private volatile Context context;

    @Override
    public SQSBatchResponse handleRequest(SQSEvent input, Context context) {
        this.context = context;
        ...
    }

    @ApplicationScoped
    @Produces
    public ContextHolder context() {
        return () -> context;
    }
}

@ApplicationScoped
public class AnyOtherBean {
    @Inject
    private ContextHolder contextHolder;
}

我不确定这种方式是否正确且最优。

还有一种更简洁的实现版本：让Lambda类直接实现ContextHolder接口，直接返回Context引用：

@ApplicationScoped
public class LambdaEntryPoint implements ContextHolder, RequestHandler<SQSEvent, SQSBatchResponse> {

    private volatile Context context;

    @Override
    public SQSBatchResponse handleRequest(SQSEvent input, Context context) {
        this.context = context;
    }

    @Override
    public Context getContext() {
        return context;
    }
}

两种实现的分析与结论 #

第一种实现（独立ContextHolder接口+生产者方法） #

• 优点：职责划分清晰，Lambda类专注于请求处理逻辑，ContextHolder的生产逻辑独立，后续若需调整Context的获取方式，无需改动请求处理的核心代码。
• 注意事项：@Produces方法上的@ApplicationScoped可以省略，因为生产者方法所在的类已经是@ApplicationScoped，会自动继承该作用域；volatile关键字必须保留，确保context变量在多线程环境下的可见性（Quarkus可能复用Lambda实例处理不同请求）。

第二种实现（Lambda类实现ContextHolder） #

• 优点：代码更简洁，减少了额外的接口实现类和生产者方法，直接复用LambdaEntryPoint实例提供Context。
• 注意事项：同样需要保留volatile关键字保证线程安全；这种方式将请求处理与Context持有两个职责合并到同一类中，虽代码量少，但违反单一职责原则——后续调整Context逻辑或请求处理逻辑时，都需修改同一个类，维护成本会随项目规模增大而上升。

最优选择建议 #

如果应用逻辑简单、无复杂扩展需求，第二种简洁实现完全可用，不会有问题。若项目规模较大，或未来可能需要扩展Context的获取逻辑（比如不同场景下提供不同Context实现），第一种职责分离的方式更利于长期维护。

另外需要注意：在Quarkus Lambda环境中，ApplicationScoped Bean会被复用，因此每次handleRequest调用时必须覆盖context变量，避免残留上一次请求的Context数据。

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