慢弹簧上下文初始化

Question

Our context init jumped from 60 sec to about 15 minutes. In both the slow and fast cases, it does eventually start up successfully. There are no fatal errors either way. Are there particular logging settings or even suggested classes to set breakpoints (or add breakpoint logging)?

I've already found the revision where that behavior started, but it is not clear what's causing it to take so much longer. I've set breakpoints throughout DefaultListableBeanFactory among others. It's a big application, so at points the call stack is hundreds deep in getting and creating beans, but comparing that against the prior revision (which finishes quickly) shows a similar nature. Nothing appears out of the ordinary, between the slow and fast revisions.

I've paused execution at random points through "the slow part" and the stack trace appears reasonable, instantiating new beans as needed, setting properties where possible (which expectably leads to more recursive doCreateBean calls, etc...).

I haven't yet bothered to set up a profiler, but doubt that it will be useful. The code that the slow revision spends all its time in (bean factory, context init), is of course the same code that the fast revision spends most its time in too.

Answer 1

You might want to check a verbose GC log. It could be that it's creating a lot of objects somehow and you would see either 1) the heap growing constantly indicating 'extra' beans or 2) a lot of nursery GC's indicating a lot of object creation but not much sticking around (by being added to the context).

For #1, a tool like Eclipse MAT will help you analyze a heap dump for the objects that are taking the most memory.

For #2, a profiler would still help. Look at number of calls made, not time spent. You would want to find constructors or other create / init methods that are being called a huge amount of times. From there you can trace back up to find the offending bean.