問題描述：
線上一個服務的突然掛了，無法被調用，查看該服務日志發現Dubbo的線程池全滿了：
2019-11-22 14:35:26.271 WARN 26516 --- [New I/O server worker #1-2] c.a.d.c.t.support.AbortPolicyWithReport : [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.10.26:12350, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 6786 (completed: 6586), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.10.26:12350!, dubbo version: 2.6.2, current host: 192.168.10.26
沒有多少訪問量，但是線程卻猛增，猜測可能是哪里出現了死循環或者哪里發生了死鎖。
首先，檢測一下服務器的CPU使用量，發現在正常范圍內，基本上可以排除哪里出現了死循環。
先找出該服務的進程，用jstack命令dump線程在分析。
"DubboServerHandler-192.168.10.26:12350-thread-200" #240 daemon prio=5 os_prio=0 tid=0x00007ffa7c141800 nid=0x6c89 waiting on condition [0x00007ffa17c7c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0d24020> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:441)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:362)
at redis.clients.util.Pool.getResource(Pool.java:49)
at redis.clients.jedis.JedisPool.getResource(JedisPool.java:226)
at (RedisHelper.java:322)
at (RedisHelper.java:106)
at BlockResourceManager.java:54)
- locked <0x00000000e0ec22d0>
可以看到最后一條線程locked <0x00000000e0ec22d0>，說明它持有着這個鎖，而其他線程狀態都是waiting to lock <0x00000000e0ec22d0>。
看來就是這條線程導致了其他線程被阻塞。
那么又是什么導致這條線程不能快速釋放鎖呢？
繼續看上面的信息，應該是從JedisPool中獲取JedisClient，但是池中一直沒有可用的客戶端，所以被阻塞。
最后的原因是一個方法中使用完客戶端沒有返回給池，導致客戶端資源被耗盡。