Why is tomcat using more and more heap space during idling?

Question

I start tomcat using startup.bat and do nothing more with it. It is a plain vanilla installation (Version 7.0.47), as far as I know. When connecting with a JMX tool, like VisualVM I see the usage of Heap space constantly increasing. Until some garbage collection happens. And then it starts all over, again.

Why is that so? What is tomcat doing there?

Is my understanding right, that it constantly generates new Objects?

As suggested by @Thilo I took snapshots of the heap histogram. It seems to create mostly Arrays of Objects, chars and bytes. The picture below shows a diff between two snapshots taken 3 minutes apart.

As the "Per thread allocations" view indicates, it has something to do with RMI, because here the most increase can be seen.

Answer 1

The short answer: Don't worry about it, this is perfectly normal. :-)

The long* answer, as @Gimby suggests, is that Tomcat (like most servers) has multiple threads running all the time, to do monitoring of resources and things like health check etc. These threads wake up at intervals and creates a lot of short-lived objects. The GC (garbage collector) will not collect these objects right away. A profiling application will see that the heap continually increases for a regular interval, or until a threshold value is reached and then suddenly drops. The drop is caused by the GC kicking in, collecting all the short lived objects in one sweep. This will cause the "saw tooth" pattern you see. Again, this is perfectly normal.

If you're interested, read more about Java garbage collection at Oracles Java tutorial pages.

The only thing to watch out for, is when the peaks of the saw tooth pattern becomes increasingly higher, or the duration between each peak becomes shorter. This might indicate a resource/reference leak in the application. In most cases though, it's just your application using more memory, because it actually does things.

---

*) I'm sure someone can provide a much longer and more in-depth answer than this, but that's better suited for a blog or technical article. ;-)