How to profile spring-boot application memory consumption?

Question

I have a spring-boot app that I suspect might have a memory leak. Over time the memory consumption seems to increase, taking like 500M of memory until I restart the application. After a fresh restart it takes something like 150M. The spring-boot app should be a pretty stateless rest app, and there shouldn't be any objects left around after request is completed. I would wish the garbage collector would take care of this.

Currently on production the spring-boot app seems to use 343M of memory (RSS). I got the heapdump of the application and analysed it. According to the analysis the heapdump is only 31M of size. So where does the missing 300M lie in? How is the heapdump correlated with the actual memory the application is using? And how could I profile the memory consumption past the heapdump? If the memory used is not in the heap, then where is it? How to discover what is consuming the memory of the spring-boot application?

Answer 1

We can view how much of memory consumption in spring boot app, in this way.

1. Create spring boot app as .jar file and execute it using java -jar springboot-example.jar

2. Now open the CMD and type jconsole and hit enter.

   Note :- before opening the jconsole you need to run .jar file

3. Now you can see a window like below and it will appear application that previously ran in Local Process section.

4. Select springboot-example.jar and click below connect button.

5. After it will show the below prompt and give Insecure connection option.

6. Finally you can see Below OverView (Heap Memory, Threads...).

Answer 2

Besides heap, you have thread stacks, meta space, JIT code cache, native shared libraries and the off-heap store (direct allocations).

I would start with thread stacks: how many threads does your application spawn at peak? Each thread is likely to allocate 1MB for its stack by default, depending on Java version, platform, etc. With (say) 300 active threads (idle or not), you'll allocate 300MB of stack memory.

Consider making all your thread pools fixed-size (or at least provide reasonable upper bounds). Even if this proves not to be root cause for what you observed, it makes the app behaviour more deterministic and will help you better isolate the problem.