问题运维响应：redis客户端连接过多，超过默认最大限制1W。执行命令./redis-cli–hhost–pportinfoclients查看redis客户端连接数，一共6个节点，每个节点2000+分析执行命令./redis-cli–hhost–p端口client列表查看具体连接信息，有大量空闲连接，主节点上有大量cmd=null，从节点上有大量cmd=readonly，空闲时间和连接的age时间都差不多，说明大部分连接没有被使用。发现Jedis连接池的minEvictableIdleTimeMillis和timeBetweenEvictionRunsMillis都配置为-1。是不是Jedis连接池没有及时回收连接的问题？但是maxTotal配置是20，一共30+个组件，应该不会超过这个值！写个脚本，先用jps查看组件pid，然后netstat–tanlp|greppid|wc-l统计每个组件的连接数，发现每个组件都超过这个值十次，平均200+。断点进入Jedis连接池中实现空闲连接检测的GenericObjectPool.evict()方法，发现IdleObjects一直为0，没有需要丢弃的空闲连接。基于对commons-pool2的信任，以及同一个组件的druid连接池没有问题（都是用commons-pool2实现自己的连接池），我觉得问题应该出现在别处。打开java进程的jmx功能（或者使用idea的remote远程调试功能），进一步分析，配置如下（看重点了解功能）：-Djava.rmi.server.hostname=IP-Dcom。sun.management.jmxremote。port=Port-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false使用jvisualvm连接目标组件，发现commons-pool-evictor-thread线程空闲到确定Jedis连接池中没有多余的连接可以丢弃。分析了一下，再看，发现框架里面一直运行着很多redisson-netty开头的线程。框架中确实使用了redisson，大部分配置项都使用默认值。下个断点，SpringContextUtil.getBean(RedissonClient.class)获取RedissonClient看看就知道了！connectionManager下的connectionWatcher记录了使用的Redis连接！太多了，lastUsageTime是组件刚启动的时候，说明还没有使用！而且6个节点每个都有32个连接，加上Pubsub连接数和Jedis连接池数，和统计的一模一样！解决问题应该是这里，设置Redisson的SlaveConnectionMinimumIdleSize和MasterConnectionMinimumIdleSize为1，重启组件对比连接数O~K~还是个配置坑--！
