Spring Kafka Template：使用Bean实例还是自定义实例？

基于业务需求封装了具备通用功能的Kafka Template包装类，目前纠结两种消息发送实现方式的合理性：

• send1：调用时传入外部的Kafka Template Bean引用
• send2：直接使用包装类内部维护的Kafka Template实例

send2的抽象方式更简洁，但担心后续会引发问题，目前两种方式均能正常向Topic发送消息，相关代码如下：

抽象包装类代码 #

public abstract class AbstractKafkaTemplate<K, V> {
  private KafkaTemplate<K, V> kafkaTemplate;

  public KafkaTemplate<K, V> createKafkaTemplate() {
    kafkaTemplate = new KafkaTemplate<>(getKafkaProducerFactory());
    return kafkaTemplate;
  }


  public void send1(Message<V> message, KafkaTemplate<K, V> kafkaTemplate) {
    kafkaTemplate.send(message);
  }

 public void send2(Message<V> message) {
    this.kafkaTemplate.send(message);
  }

}

子类实现代码 #

@Component
public class DemoKafkaTemplate extends AbstractKafkaTemplate<String, String> {

  @Bean(name = "DEMO_KAFKA_TEMPLATE_NAME")
  public KafkaTemplate<String, String> createkafkaTemplateBean() {
    return createKafkaTemplate();
  }

}

生产者调用代码 #

@Component
public class DemoProducer {

  @Autowired
  @Qualifier("DEMO_KAFKA_TEMPLATE_NAME")
  KafkaTemplate kafkaTemplate;

  @Autowired
  DemoKafkaTemplate demoKafkaTemplate;


 public void send(Event<String> event) {

// 方式1：传入外部Kafka Template实例
       demoKafkaTemplate.send1(msg,kafkaTemplate);

// 方式2：使用包装类内部实例
       demoKafkaTemplate.send2(msg);
 

 }


}

分析与结论 #

1. send2当前实现的潜在风险 #

当前send2依赖抽象类内部的kafkaTemplate实例，而这个实例是通过createKafkaTemplate()方法创建并赋值的。虽然现在DemoKafkaTemplate的Bean创建逻辑调用了该方法，让内部实例与Spring容器中的Bean保持一致，但存在以下隐患：

• 如果后续子类或其他代码再次调用createKafkaTemplate()，会重新创建一个KafkaTemplate实例并覆盖抽象类中的kafkaTemplate，导致send2使用的实例与Spring容器中的Bean不一致，出现配置混乱、连接池冲突等不可预期的问题。
• 抽象类内部维护的kafkaTemplate是私有状态，子类无法管控其生命周期，增加了维护成本和出错概率。

2. send1的优缺点 #

• 优点：传入的KafkaTemplate是Spring管理的单例Bean，实例稳定，不会被意外替换，避免了状态不一致的问题。
• 缺点：调用时必须手动传入实例，违背了包装类"封装通用逻辑、简化调用"的设计初衷，增加了调用者的负担，也容易出现传错实例的低级错误。

3. 推荐的优化方案 #

重构抽象类，让其依赖Spring管理的KafkaTemplate实例，而非自行维护内部状态，既保留send2的简洁性，又消除潜在风险：

修改后的抽象包装类

public abstract class AbstractKafkaTemplate<K, V> {
    // 用protected final确保实例稳定且子类可访问
    protected final KafkaTemplate<K, V> kafkaTemplate;

    // 通过构造注入Spring管理的KafkaTemplate实例
    protected AbstractKafkaTemplate(KafkaTemplate<K, V> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    // 统一的send方法，可在此添加通用逻辑（日志、消息转换、拦截等）
    public void send(Message<V> message) {
        kafkaTemplate.send(message);
    }
}

修改后的子类实现

@Component
public class DemoKafkaTemplate extends AbstractKafkaTemplate<String, String> {

    // 创建Spring管理的KafkaTemplate Bean
    @Bean(name = "DEMO_KAFKA_TEMPLATE_NAME")
    public KafkaTemplate<String, String> createkafkaTemplateBean() {
        return new KafkaTemplate<>(getKafkaProducerFactory());
    }

    // 构造注入自身创建的KafkaTemplate Bean到父类
    public DemoKafkaTemplate(@Qualifier("DEMO_KAFKA_TEMPLATE_NAME") KafkaTemplate<String, String> kafkaTemplate) {
        super(kafkaTemplate);
    }
}

修改后的生产者调用

@Component
public class DemoProducer {

  @Autowired
  DemoKafkaTemplate demoKafkaTemplate;

 public void send(Event<String> event) {
       // 直接调用封装后的send方法，无需关心KafkaTemplate细节
       demoKafkaTemplate.send(msg);
 }
}

这种方案的核心优势：

• 抽象类不再维护可变状态，依赖的KafkaTemplate是Spring管理的单例，实例稳定可靠。
• 调用方式简洁，完全符合包装类的设计目的，调用者无需感知KafkaTemplate的存在。
• 通用逻辑可以统一放在抽象类的send方法中，易于维护和扩展。

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