我們的java服務器集羣在發佈的時候，會出現剛發佈的服務器load飆高（超過cpu核數）的問題，過幾分鐘才能回到低位，分析了好久也沒發現什麼原因。
經過查閱相關資料，我們意識到jvm在剛啓動時，性能並不是最好的狀態，在隨後的運行過程中，它會自動分析熱點（運行頻率高的的代碼），並對熱點代碼進行優化，所以jvm運行一段時間後才能獲得較好的性能。這個問題在體量較小的應用中無法體現，當qps達到較高水平時，纔會出現這個問題。
但網上查到的資料也就到這裏了，並沒有給出解決方案。於是綜合自己的思考，以及與某大型互聯網公司員工的探討，發現了這個解決方案：降低剛發佈的服務器的權重，讓它的相對流量變小，然後逐漸加大權重，給它充分的預熱時間。
具體的實施方案要分應用，比如web應用的負載均衡，我們用到了阿里雲的SLB，發佈時需要調用SLB的api，逐漸加大權重。
對於RPC，比如dubbo，需要在provider啓動註冊自己到zk時加入服務啓動時間，consumer取到這個時間，跟當前時間對比，在10分鐘內逐漸提高權重到正常值。實踐的時候發現dubbo已經在RandomLoadBalance寫了這種實現方式，但不幸的是有bug。在我fork的源碼中已經修復了該問題：https://github.com/aftersss/dubbo