背景
2.7.1的dubbo，預設情況下，消費者在接收傳回消息時，會将消息指定到all的Dispatcher中，然後将消息丢入線程池等待排程處理，消費者接收消息使用的線程池預設是cached（緩存線程池），此時會存在兩個問題：
線程池建立過多；
線程池線程數無限制；
第一個問題是因為dubbo的線程模型中，線程池的個數與用戶端引用的服務個數，服務提供者的數量，connections都有關，總的來說消費者與提供者建立一條連接配接，則消費者建立一個線程池處理傳回消息，即：
消費方線程池個數 = Reference服務1的提供者數量 * connections + Reference服務2的提供者數量 * connections + ……
注意：這隻是線程池的個數，實際線程數量與線程池的threads數量有關.
若服務1和服務2存在相同位址的服務提供者，則線程池隻建立一個
第二個問題是因為緩存線程池的預設最大線程數為2147483647（Integer的最大值，約21億）。這兩個問題最終都可能會導緻建立過多線程，進而引發性能問題。
消費端何時設定的線程池？
在初始化NettyClient時，若使用者在未指定threadpool參數時，會指定預設線程池為cached。
這裡添加線程池的預設值為cached 。添加線程池後的url會在後續的handler中使用。
緩存線程池有何問題？
預設情況下，最大線程數為Integer的最大值，故而導緻在請求集中一個時間點傳回的情況下，建立過多的線程進而引發性能問題。
源碼NettyServer、AllChannelHandler、WrappedChannelHandler
2.7.3以上官方已經修複，沒這個問題了