本文介绍通过手动管理 kafkaconsumer 替代 @kafkalistener，实现对消息消费速率（如每秒 10 万条）和内存队列容量（如 100 万条）的精准控制，避免 oom 风险。
本文介绍通过手动管理 kafkaconsumer 替代 @kafkalistener，实现对消息消费速率（如每秒 10 万条）和内存队列容量（如 100 万条）的精准控制，避免 oom 风险。
在 Spring Batch 集成 Kafka 场景中，直接使用 @KafkaListener + 无界队列（如 ConcurrentLinkedQueue）极易导致内存溢出——因为监听器默认以最大吞吐优先，持续拉取消息并堆积至 JVM 堆内存。根本解法是放弃被动监听，转为显式、可控的主动轮询机制，即用原生 KafkaConsumer 替代注解驱动模型。
✅ 正确实践：手动轮询 + 容量感知
首先，构建带限流参数的 KafkaConsumer 实例：
Map<string object> consumerConfig = Map.of(
"bootstrap.servers", "localhost:9092",
"key.deserializer", StringDeserializer.class.getName(),
"value.deserializer", StringDeserializer.class.getName(),
"group.id", "batch-processor",
"max.poll.records", 10000, // 单次 poll 最多返回 1 万条（防单次过载）
"fetch.max.wait.ms", 500, // 若无足够数据，最多等待 500ms
"fetch.min.bytes", 1024 // 至少累积 1KB 数据才返回（提升吞吐效率）
);
KafkaConsumer<string message> kafkaConsumer = new KafkaConsumer(consumerConfig);
kafkaConsumer.subscribe(List.of("topic"));</string></string>
⚠️ 注意：
max.poll.records是核心限流参数，需结合业务吞吐与内存预算设定（例如设为 10,000，则每轮最多入队 1 万条）。
接着，在消费逻辑中加入队列容量守门机制：
receive()
