其實 lz 一直限制在了取系統時間耗時的問題上，是以，一直想變相的通過各種手法排除掉擷取系統時間的邏輯，比如使用“次數”來對連接配接實作逾時控制，但其實，使用次數來表示逾時控制本身就是個僞命題， 比如，在逾時次數的閥值是100，如果在90次後，就一直沒有被其他線程使用，一直不到閥值，那怎麼去将這個連接配接釋放掉呢？
是以，我想到了另外一種方式解決這個問題：
首先，要明确，我認為取系統時間可以取的，但是不一定要擷取連接配接的這個線程去做這個事情，比如交給其他線程去做，模型可能是這樣：
1. 線程a 拿到連接配接，調用refresh方法
2.refresh方法中，将連接配接自己放到一個隊列中，後傳回。
3. 某個特殊線程s不停的去隊列中拿元素，并且，将拿到的元素和拿到時刻的時間記錄下，封裝好交給hash環 h, h是一個類似hashmap的hash環，隻不過頭尾相接。
4. timer線程t不停的去周遊h，将逾時時間大于某個閥值的連接配接拿掉，設定為逾時連接配接。
不過這裡需要注意到幾個問題：
1. 考慮到connection不會無限制增多，設計成環，環并不會無限制增大，是以，可行。
2. 更仔細點，可以将connection中放一個标志位，标示是否正在使用，timer掃描時，逾時間在使用狀态，或者逾時間不使用的連接配接（标準可能不同，在被使用的，可能時間要長一點。）都可以判定為逾時連接配接
3. 因為連接配接數有限，是以，線程s的隊列中，也不會太長（每個連接配接一個位子）。
4. 通過線程s的接入，将去系統時間等耗時操作從連接配接轉移到了線程s中，提高s線程的處理速度。
5. 線程s或許還可以一次從隊列中取出多個元素，統一取一次系統時間，将取出來的多個元素設定為該時間，整個操作在毫秒内完成，可以用一個時間約等于各自連接配接時的真正時間，降低系統時間的擷取頻率。
6……. 歡迎補充。
以一個線程s的代價，加快了各個連接配接所線上程的處理速率，值。