看来你遇到的问题是多个线程执行brpop阻塞命令时，因为队列空导致线程互相等待Redis连接——这其实和Spring Redis的连接池机制密切相关，我来给你拆解解决方案：

核心原因 #

StringRedisTemplate本身是线程安全的，但它依赖RedisConnectionFactory来管理连接，默认使用连接池（不管是Lettuce还是Jedis）。当brpop命令阻塞时，当前线程会一直占用从连接池获取的连接，如果你的连接池最大活跃连接数设置得太小，当阻塞线程数超过连接池容量时，后续线程就会等待空闲连接释放，也就是你看到的“等待其他阻塞线程的Redis连接”。

具体解决方案 #

1. 调整连接池配置，确保容量足够 #

最直接的方法是根据你的阻塞线程数量，调大连接池的最大活跃连接数。比如用Lettuce作为客户端的话，配置示例如下：

@Bean
public LettuceConnectionFactory redisConnectionFactory() {
    // 连接池配置
    GenericObjectPoolConfig<Object> poolConfig = new GenericObjectPoolConfig<>();
    poolConfig.setMaxTotal(30); // 设置为大于你的阻塞线程数的值
    poolConfig.setMaxIdle(20);
    poolConfig.setMinIdle(5);
    poolConfig.setBlockWhenExhausted(true); // 连接耗尽时是否等待，默认true，可根据需求调整

    LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
            .poolConfig(poolConfig)
            .build();

    RedisStandaloneConfiguration standaloneConfig = new RedisStandaloneConfiguration("localhost", 6379);
    return new LettuceConnectionFactory(standaloneConfig, clientConfig);
}

如果用Jedis客户端，配置逻辑类似，只需要替换对应的连接工厂和池配置类即可。

2. 用RedisCallback确保独立连接执行brpop #

如果你需要更精细化的连接控制，可以直接使用RedisCallback来执行brpop，这样每次调用都会从连接池获取独立的连接，避免任何潜在的连接共享问题：

String result = stringRedisTemplate.execute((RedisCallback<String>) connection -> {
    // 这里的connection是当前线程独立获取的连接
    byte[] popResult = connection.bRPop(0, "your-target-queue".getBytes(StandardCharsets.UTF_8));
    return popResult != null ? new String(popResult, StandardCharsets.UTF_8) : null;
});

这种方式下，brpop阻塞期间会一直占用该连接，直到队列有数据返回或超时，之后连接会自动归还到连接池。

3. 避免手动持有RedisConnection实例 #

千万别在多个线程之间共享同一个RedisConnection实例——它不是线程安全的。StringRedisTemplate已经帮你封装了连接的获取和释放逻辑，尽量通过它的API或者RedisCallback来操作，不要手动获取连接后长期持有。

额外提示 #

如果你的业务场景中有大量长期阻塞的brpop线程，建议监控Redis连接池的状态（比如空闲连接数、活跃连接数），避免连接池耗尽导致服务不可用。另外，也可以考虑给brpop设置合理的超时时间，避免连接被永久占用。

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