Jedis湧現connection timeout成績處理辦法（JedisPool銜接池應用實例）。本站提示廣大學習愛好者：（Jedis湧現connection timeout成績處理辦法（JedisPool銜接池應用實例））文章只能為提供參考，不一定能成為您想要的結果。以下是Jedis湧現connection timeout成績處理辦法（JedisPool銜接池應用實例）正文
明天發明Jedis 默許的銜接方法 jedis=new Jedis(“localhost”,6379)，總是產生connection timeout. 後來發明jedis類包還有一種可以設置最年夜銜接時光的辦法。
1->獲得Jedis實例須要從JedisPool中獲得；
2->用完Jedis實例須要還給JedisPool；
3->假如Jedis在應用進程中失足，則也須要還給JedisPool；
代碼以下
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxActive(100);
config.setMaxIdle(20);
config.setMaxWait(1000l);
JedisPool pool;
pool = new JedisPool(config, "2xx.xx.xx.14", 6379);
boolean borrowOrOprSuccess = true;
try {
jedis = pool.getResource();
// do redis opt by instance
} catch (JedisConnectionException e) {
borrowOrOprSuccess = false;
if (jedis != null)
pool.returnBrokenResource(jedis);
} finally {
if (borrowOrOprSuccess)
pool.returnResource(jedis);
}
jedis = pool.getResource();
JedisPool依附apache類包
commons-pool-1.5.6.jar
1->固然拋出JedisConnectionException，但現實上有兩類毛病，一類是pool.getReource()，得不到可用的jedis實例；另外一類是jedis.set/get時失足也會拋出這個Exception；為了完成辨別，所以依據instance能否為null來完成，假如為空就證實instance基本就沒初始化，也就不消return給pool；假如instance不為null，則證實是須要返還給pool的；
2->在instance失足時，也要挪用returnBrokenResource返還給pool，不然下次經由過程getResource獲得的instance的緩沖區能夠還存在數據，湧現成績！
JedisPool的設置裝備擺設參數很年夜水平上依附於現實運用需求、軟硬件才能。之前沒用過commons-pool，所以此次花了一整間專門看這些參數的寄義。。。JedisPool的設置裝備擺設參數年夜部門是由JedisPoolConfig的對應項來賦值的。
maxActive：掌握一個pool可分派若干個jedis實例，經由過程pool.getResource()來獲得；假如賦值為-1，則表現不限制；假如pool曾經分派了maxActive個jedis實例，則此時pool的狀況就成exhausted了，在JedisPoolConfig
maxIdle：掌握一個pool最多有若干個狀況為idle的jedis實例；
whenExhaustedAction：表現當pool中的jedis實例都被allocated完時，pool要采用的操作；默許有三種WHEN_EXHAUSTED_FAIL（表現無jedis實例時，直接拋出
NoSuchElementException）、WHEN_EXHAUSTED_BLOCK（則表現壅塞住，或許到達maxWait時拋出JedisConnectionException）、WHEN_EXHAUSTED_GROW（則表現新建一個jedis實例，也就說設置的maxActive無用）；
maxWait：表現當borrow一個jedis實例時，最年夜的期待時光，假如跨越期待時光，則直接拋出JedisConnectionException；
testOnBorrow：在borrow一個jedis實例時，能否提早停止alidate操作；假如為true，則獲得的jedis實例均是可用的；
testOnReturn：在return給pool時，能否提早停止validate操作；
testWhileIdle：假如為true，表現有一個idle object evitor線程對idle object停止掃描，假如validate掉敗，此object會被從pool中drop失落；這一項只要在timeBetweenEvictionRunsMillis年夜於0時才成心義；
timeBetweenEvictionRunsMillis：表現idle object evitor兩次掃描之間要sleep的毫秒數；
numTestsPerEvictionRun：表現idle object evitor每次掃描的最多的對象數；
minEvictableIdleTimeMillis：表現一個對象至多逗留在idle狀況的最短時光，然後能力被idle object evitor掃描並驅趕；這一項只要在timeBetweenEvictionRunsMillis年夜於0時才成心義；
softMinEvictableIdleTimeMillis：在minEvictableIdleTimeMillis基本上，參加了至多minIdle個對象曾經在pool外面了。假如為-1，evicted不會依據idle time驅趕任何對象。假如minEvictableIdleTimeMillis>0，則此項設置有意義，且只要在timeBetweenEvictionRunsMillis年夜於0時才成心義；
lifo：borrowObject前往對象時，是采取DEFAULT_LIFO（last in first out，即相似cache的最頻仍應用隊列），假如為False，則表現FIFO隊列；
個中JedisPoolConfig對一些參數的默許設置以下：
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1
