When you're running a dynamic application (and most of the languages we teach these days are dynamic), memory is allocated and released as necessary at run time, with allocation happening 'as required' and being released from time to time by a garbage collector - there is no point is collecting a few bytes of memory every time that there is some released as that would be very inefficient - rather like calling out your local council to collect your rubbish every time you finished a packet of crisps. So if you look at a graph of memory usage, you'll see a saw-toothed shape like this:
In Java, data (objects) are held in memory in different areas, and moved around between them, to make the memory management and garbage collection more efficient, and the memory areas each have their own names.
New objects are allocated memory in the Eden Space
memory pool (as in created in Eden) and by the nature of most applications in which the majority of objects only survive for a short while, that's where they remain for their short lives. Here is a graph showing the size of Eden Space alone - you'll notice the same general saw toothed shape, but the curve drops virtually to zero at the base of every tooth:
At minor garbage collection time, objects which survive garbage collection are moved to the Survivor Space
which, as the name implies, is used for objects that have a longer life span / expectancy. Here's a graph of survivor space - you'll see some gentle ups and downs but in general a much smoother curve!
And that minority of objects that aren't going to be going away but are 'around for the duration' become a part of the Tenure
space. I wouldn't describe the graph for tenure as a curve - more like a straight line!
All four sample graphs are taken from jconsole
, monitoring a Tomcat server that's ticking over with just a few test connections / pages being served.
There are also other memory pools used and shown by jconsole - there's the code cache
where the code that's being run - both Tomcat itself and the classes it is running - resides, and you have permanent areas too - one "rw" (read / write) and one that is "ro" (read only). The code cache graph looks somewhere between the survivor and tenure in shape:
And the permanent areas are close to being flat files (I haven't reproduced them here!) (written 2009-03-14, updated 2012-10-13)
Associated topics are indexed underA506 - Web Application Deployment - Java - Installing and Deploying optional Technologies 
Gathering information - logging - with log4j. First steps. - (2010-11-12) 
Jmeter - a first test case - (2009-03-14) 
Connecting jconsole remotely - the principles - (2009-03-14) 
Increasing Java Virtual Machine memory for Tomcat - (2008-07-24)A692 - Web Application Deployment - Monitoring and load testing your server 
Server logs - drawing a graph of gathered data - (2010-11-03) 
Apache httpd Server Status - monitoring your server - (2010-10-28) 
Logging the performance of the Apache httpd web server - (2010-10-25) 
Monitoring and loading tools for testing Apache Tomcat - (2009-07-07) 
Using ApacheBench and jconsole to test and monitor Tomcat - (2009-03-14)A503 - Web Application Deployment - Java - Sourcing, Installing, Initial Testing 
Choosing the right version of Java and Tomcat - (2009-05-16) 
Class Loading and Variable Conversion in Java - (2009-05-02) 
Java CLASSPATH explained - (2008-11-26)A901 - Replaced Page 
Apache Tomcat Performance Tuning - (2007-09-29)
Some other Articles
Do you support a decent train service? Please sign up!Java - Memory Allocation and garbage collectionA lot has changed - but the memory lingers onWhy put Apache httpd in front of Apache TomcatA New Advert for Well House ManorSupporting Parkinsons and TrainsWeekday or Weekend PHP, Python and Perl classes?