ConnectionPoolConfig+UnifiedJedis+Transaction使用疑问（redis.clients 4.4.0-rc1）

1. 当前ConnectionPoolConfig的使用方式是否正确？ #

你的配置整体方向没问题，但有几个细节需要调整：

• 静态初始化connectionPoolConfig和JedisPooled实例是正确的，JedisPooled本身线程安全，多线程共享同一个实例能避免重复创建连接池。
• 部分配置项会影响性能：
  • setTestOnBorrow(true)和setTestOnReturn(true)会在获取/归还连接时做连通性测试，虽能保证连接有效性，但会增加额外开销，高并发场景建议关闭，仅保留TestWhileIdle即可。
  • setMaxIdle(50)和setMinIdle(50)设为相同值，意味着连接池会固定维持50个空闲连接，适合负载稳定的场景；若负载波动大，可降低MinIdle让连接池自动伸缩。
• 缺少异常处理：事务执行中若抛出异常，连接可能无法正常归还到池内，建议用try-finally块确保资源释放。

2. poolConfig.setMaxTotal()的作用及连接数超标的原因 #

setMaxTotal()的作用 #

该方法设置连接池允许创建的最大总连接数，包含正在使用的活跃连接和空闲连接。当请求连接数超过此值时，新请求会根据blockWhenExhausted设置（你设为true）进入阻塞等待，直到有连接归还或超时。

连接数超过500的可能原因 #

1. 连接泄漏：你的代码未捕获事务操作的异常，一旦jsonSetLegacy或exec()抛出异常，对应连接可能无法归还。大量泄漏时，连接池会持续创建新连接满足请求，甚至突破maxTotal限制。建议修改代码添加try-finally：

for (int i = 0; i < 500; i++) {
    Transaction tr = null;
    try {
        tr = jedis.multi();
        tr.jsonSetLegacy(System.currentTimeMillis() + " - " + Thread.currentThread().getId() + "ABC","Value");
        tr.exec();
    } finally {
        if (tr != null) {
            try {
                tr.discard(); // 确保连接归还，即使exec失败
            } catch (Exception e) {
                // 忽略释放异常
            }
        }
    }
}

2. 版本bug：你使用的4.4.0-rc1是候选版本，可能存在连接池或事务连接处理的bug，导致连接未被正确回收。建议升级到稳定版本（如4.4.0正式版）后重试。
3. 统计误差：RedisInsight显示的连接数可能包含已关闭但未被Redis服务器回收的TIME_WAIT状态连接，这类连接并非活跃连接，不会占用连接池资源。可通过INFO clients命令查看Redis实际活跃连接数，对比验证。

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