Jedis有直连方式，所谓直连指的是Jedis每次都会新建TCP连接，使用后在断开连接，对于平凡访问Redis的场景显然不是高效的使用方式，如图：
因此生产环境一般使用连接池的方式对Jedis连接池进行管理，如图：
Jedis对象预先放在池子中（JedisPool），每次要连接Redis，只需要在池子中借，用完了在归还给池子。
客户端连接Redis使用的是TCP协议，直连的方式每次需要建立TCP连接，而连接池的方式是可以预先初始化好Jedis连接，所以每次只需要从Jedis连接池借用即可，而借用和归还操作是在本地进行的，只有少量的并发同步开销，远远小于新建TCP连接的开销。另外直连的方式无法限制Jedis对象的个数，在极端情况下可能会造成连接泄漏，而连接池的形式可以有效的保护和控制资源的使用。但是直连的方式也并不是一无是处，下表给出两种方式各自的优劣势：
- 直连 优点：简单方便，适用于少量长期连接的场景，缺点：1>存在每次新建/关闭TCP连接开销。2>资源无法控制，极端情况会出现连接泄漏。3>Jedis对象线程不安全。
- 连接池 优点：1>无需每次连接都生成Jedis对象，降低开销。2>使用连接池的形式保护和控制资源的使用。缺点：相对于直连，使用相对麻烦，尤其在资源的管理上需要很多参数来保证，一旦不合理也会出现问题。
Jedis提供了JedisPool这个类作为对Jedis的连接池，同时使用了Apache的通用对象池工具common-pool作为资源的管理工具，下面是使用JedisPool操作Redis的代码示例：
1）Jedis连接池（通常JedisPool是单例的）：
//common-pool连接池配置，这里使用默认配置，后面小节会介绍具体配置说明
GenericObjectPoolConfig poolConfig=new GenericObjectPoolConfig();
//初始化Jedis连接池
JedisPool jedisPool=new JedisPool(poolConfig,"127.0.0.1",6379);
- 获取Jedis对象不再是直接生成一个Jedis对象进行直连，而是从连接池直接获取，代码如下：
Jedis jedis =null;
try {
//1.从连接池获取jedis对象
jedis=jedisPool.getResource();
//2.执行操作
jedis.get("hello");
} catch (Exception e) {
logger.error(e.getMessage(),e);
}finally{
if(jedis!=null){
//如果使用JedisPool,close操作不是关闭连接，代表归还连接池
jedis.close();
}
}
这里可以看到finally中依然是jedis.close()操作，为什么会把连接关闭呢，这不和连接池的原则违背吗？但实际上Jedis的close()实现方式如下：
public void close(){
//使用Jedis连接池
if(dataSource!=null){
if(client.isBroken()){
this.dataSource.returnBrokenResource(this);
}else{
this.dataSource.returnResource(this);
}
//直连
}else{
client.close();
}
}
参数说明：
- dataSource!=null代表使用的是连接池，所以jedis.close()代表归还连接给连接池，而且Jedis会判断当前连接是否已经断开。
- dataSource=null代表直连，jedis.close()代表关闭连接。
前面GenericObjectPoolConfig使用的是默认配置，实际它提供有很多参数，例如池子中最大连接数，最大空闲连接数，最小空闲连接数，连接活性检测，等等，例如下面代码：
GenericObjectPoolConfig poolConfig=new GenericObjectPoolConfig();
//设置最大连接数为默认值的5倍
poolConfig.setMaxTotal(GenericObjectPoolConfig.DEFAULT_MAX_TOTAL*5);
//设置最大空闲连接数为默认值的3倍
poolConfig.setMaxIdle(GenericObjectPoolConfig.DEFAULT_MAX_IDLE*3);
//设置最小空闲连接数为默认值的2倍
poolConfig.setMinIdle(GenericObjectPoolConfig. DEFAULT_MIN_IDLE*2);
//设置开启JMX功能
poolConfig.SetJmxEnabled(true);
//设置连接池没有连接后客户端的最大等待时间（单位为毫秒）
poolConfig.setMaxWaitMillis(3000);
GenericObjectPoolConfig的其他属性：
基本参数
lifo //GenericObjectPool 提供了后进先出(LIFO)与先进先出(FIFO)两种行为模式的池。默认为true，即当池中有空闲可用的对象时，调用borrowObject方法会返回最近（后进）的实例
fairness //当从池中获取资源或者将资源还回池中时 是否使用java.util.concurrent.locks.ReentrantLock.ReentrantLock 的公平锁机制,默认为false
数量控制参数
maxTotal //链接池中最大连接数,默认为8
maxIdle //链接池中最大空闲的连接数,默认也为8
minIdle //连接池中最少空闲的连接数,默认为0
超时参数
maxWaitMillis //当连接池资源耗尽时，等待时间，超出则抛异常，默认为-1即永不超时
blockWhenExhausted //连接耗尽时是否阻塞, false报异常,ture阻塞直到超时, 默认true。当这个值为true的时候，maxWaitMillis参数才能生效。为false的时候，当连接池没资源，则立马抛异常。默认为true
test参数
testOnCreate //默认false，create的时候检测是有有效，如果无效则从连接池中移除，并尝试获取继续获取
testOnBorrow //默认false，borrow的时候检测是有有效，如果无效则从连接池中移除，并尝试获取继续获取
testOnReturn //默认false，return的时候检测是有有效，如果无效则从连接池中移除，并尝试获取继续获取
testWhileIdle //默认false，在evictor线程里头，当evictionPolicy.evict方法返回false时，而且testWhileIdle为true的时候则检测是否有效，如果无效则移除
检测参数
timeBetweenEvictionRunsMillis //空闲链接检测线程检测的周期，毫秒数。如果为负值，表示不运行检测线程。默认为-1.
numTestsPerEvictionRun //在每次空闲连接回收器线程(如果有)运行时检查的连接数量，默认为3
minEvictableIdleTimeMillis //连接空闲的最小时间，达到此值后空闲连接将可能会被移除。默认为1000L 60L 30L
softMinEvictableIdleTimeMillis //连接空闲的最小时间，达到此值后空闲链接将会被移除，且保留minIdle个空闲连接数。默认为-1.
evictionPolicyClassName //evict策略的类名，默认为org.apache.commons.pool2.impl.DefaultEvictionPolicy
其他
jmxEnabled //是否开启jmx监控，如果应用开启了jmx端口并且jmxEnabled设置为true，就可以通过jconsole或者jvisualvm看到关于连接池的相关统计，有助于了解连接池的使用情况，并且可以针对其做监控统计，默认是true。
evictionPolicyClassName //设置的逐出策略类名, 默认"org.apache.commons.pool2.impl.DefaultEvictionPolicy"(当连接超过最大空闲时间,或连接数超过最大空闲连接数)
