使用jedis时会"偶尔"产生的一个异常,可能是jedis的bug,大家看一下.

Question

org.springframework.dao.DataAccessResourceFailureException: Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

使用的是：jedis-2.1.0.jar

Answer 1

你说的那种情况，由于设计不正确导致的问题，这边也曾经出现过。曾经一个哥们把一个很大的list序列化成二进制存到redis中，然后，一次性的取出这个对象再for循环从这个list中取出一条数据。这个是不是很崩溃啊，特别有意思吧。

而且在不注重设计的公司里这种问题的确很常见，或者说设计了但程序员偏偏特立独行，不按设计来，自己折腾份出来。结果么，也许差强人意吧。O(∩_∩)O~

Answer 2

实际上，任何现象的背后都有其存在的原因。技术者作为存在的根本因素之一就是发掘这些根本问题并且解决掉这些问题。这算是技术者的职责吧

Answer 3

不是设计的问题，是编码的问题。理论上说，也应当建立一套redis的编码规范。比如：将同等操作进行分批处理，而不是单个处理。

Answer 4

我们最近出的redis问题就是一个哥们用了一大堆的get方法，一个页面redis跟服务器端交互近200次，太频繁了。后来改成mget，pipeline的方式明显好多了 要别的页面要是跟redis交互50次会不会出问题呢?会不会和你们设计有问题

Answer 5

可能需要找到连接为什么没释放；

比如：程序里有将连接返回池中吗？

你可以试试分析java core、gc信息、应用日志、系统状态（cpu、内存、io、磁盘）等，看看哪些java进程比较忙。这些比较忙的java进程中哪些线程占用cpu的，这些占用cpu的线程都在干什么，做什么操作。线程上下文切换频繁不频繁，中断多不多。

接着，再看看网络有没有问题，redis服务器忙不忙等等。可以考虑先排除网络问题和redis服务器的问题。接着，判断应用中忙的线程到底在忙什么，是哪些场景忙，这些场景中是否redis有使用不当的地方等。

只要花点心思，认真排查，问题总能解决掉的。

我们最近出的redis问题就是一个哥们用了一大堆的get方法，一个页面redis跟服务器端交互近200次，太频繁了。后来改成mget，pipeline的方式明显好多了。

自己多分析分析，实在分析不出来再出来发帖问吧。

Answer 6

你没有把对象放回对象池 

val result = pool.getResource()
      try {
        return f(result)
      } catch {
        case e: Exception =>
          pool.returnBrokenResource(result)
          NetTool.sendErrorMailSafe(e);
          fail
      } finally {
        pool.returnResource(result)
      }

Answer 7

我遇到更坑的，不能使用64位编译的服务器

Answer 8

只能调大点连接池活动个数了

Answer 9

jedis自己维护的pool，然后自己告诉自己 连接没有资源了,这正常么

Answer 10

这不是说连接池没有可用资源了吗

Answer 11

嗯，认同的

Answer 12

说了这么多，只想告诉你，做事不可以马虎。从根本上找到问题并且解决问题才是最佳实践！