緩慢的上下文初始化

我們的上下文init從60秒跳到大約15分鐘。在緩慢和快速的情況下，它最終都會成功啓動。無論哪種方式都沒有致命的錯誤。是否有特定的日誌記錄設置，甚至建議的類來設置斷點（或添加斷點記錄）？緩慢的上下文初始化

我已經找到那個行爲開始的版本，但不清楚是什麼導致它需要更長的時間。我在整個DefaultListableBeanFactory中設置了斷點。這是一個很大的應用程序，所以調用堆棧在獲取和創建bean時已經有數百年的歷史了，但是將其與之前的修訂版本（快速完成）進行比較顯示出類似的性質。在緩慢和快速修訂之間沒有什麼不尋常的事情發生。

我已經在隨機點通過「緩慢部分」暫停執行，並且堆棧跟蹤看起來很合理，根據需要實例化新的bean，儘可能設置屬性（這可能會導致更多的遞歸doCreateBean調用等）。

我還沒有打擾建立一個分析器，但懷疑它會有用。慢版本花費在其中的代碼（bean factory，context init），當然也是快速修改其花費最多的代碼。

來源

2012-07-26 Jason Dunkelberger

Spring使用log4j，你打開調試日誌？ – 2012-07-26 23:56:17

是的，在org.springframework上調試。在一分鐘內，我有幾百兆字節的日誌。我已經搜索了最高端，作爲一個人，我發現很難消化任何有用的東西。 – 2012-07-27 16:44:38

嘗試一個利潤可能是有用的，所以你可以分析什麼是慢的部分佔用的時間 – 2012-07-27 17:03:04

您可能需要檢查詳細的GC日誌。這可能是因爲它以某種方式創建了很多對象，並且您會看到1）堆不斷增長，表明「額外」豆或2）很多幼兒園GC指示創建了很多對象，但沒有太多粘附（通過添加對上下文）。

對於＃1，像Eclipse MAT這樣的工具將幫助您分析堆內存最多的對象的堆轉儲。

對於＃2，分析器仍然有幫助。查看所撥打電話的數量，而不是花費的時間。你會想找到構造函數或其他被稱爲大量次的create/init方法。從那裏你可以追溯到找到有害的豆。

來源

2012-07-27 01:18:30 AngerClown

緩慢的上下文初始化

回答

相關問題