Take the 2-minute tour ×

I am thinking about how much a class resides in memory in case it is not being accessed by other objects in memory?

for example suppose I have some class like this:

public class OrderNumber {
 private static long counter = 0;

 public static long getOrderNumber(){
          if (counter >= 100) {
            return counter = 1;
          return ++counter;

And I call its static method from another class:

long number = OrderNumber.getOrderNumber(); 

each time I call it, it returns an incremental number, 1, 2, 3, 4, ...

So, My question is What is the probability of this method to return the initial value where it is supposed to return the sequenced value ??

share|improve this question
Are you asking about the Class Loader? en.wikipedia.org/wiki/Java_Classloader –  S.Lott Feb 23 '10 at 20:04
add comment

4 Answers

up vote 10 down vote accepted

Right now, the answer is forever. Class definitions are put into the permanent generation, and remain there until the program terminates.

Note, this is a problem for dynamic languages on the JVM, like JRuby, which create classes on the fly, because these classes waste space. I believe there are changes in the works that will resolve this problem - for example, the G1 collector

share|improve this answer
add comment

It is defined that there is effectively a strong reference from a class to its class loader instance, and from a class loader instance to every class it has ever loaded. So a class can only be unloaded at the same time as a class loader (give or take the odd finaliser resurrection trick). Every class loaded by a class loader becomes eligible for collectible at the same time.

In practice class data lives in the "permanent generation" (in HotSpot at least). This is typically garbage collected less frequently than the main heap, as it should have less churn. It's also not uncommon for class loaders to "leak". Most applications have code that last until the process is restarted. Development app servers will often reload "apps" whilst maintaining the core server/container and some library code.

IIRC, JDK 1.1 unloaded individual classes, which caused problems (Java 2 came out in 1998).

share|improve this answer
add comment

There's lots of information on class loading. Here, for example, is one article: http://www.ibm.com/developerworks/java/library/j-dyn0429/

The rules for loading classes are spelled out in detail in the JVM specification. The basic principle is that classes are only loaded when needed (or at least appear to be loaded this way -- the JVM has some flexibility in the actual loading, but must maintain a fixed sequence of class initialization). Each class that gets loaded may have other classes that it depends on, so the loading process is recursive.

Here's the JVM specification on loading. http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html

share|improve this answer
I'm not sure your third paragraph is right. Even if a Class object references the ClassLoader, it should still be eligible for collection if nothing else references it, right? AFAIK, the ClassLoader doesn't strongly reference the Class objects themselves, so the only reason they don't get collected is that they're added to the permanent generation, as daveb points out. –  Daniel Pryden Feb 23 '10 at 20:20
@Daniel Pryden: Good point. Removed. –  S.Lott Feb 23 '10 at 20:23
add comment

The java documentation indeed says forever: http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html


share|improve this answer
I just read the documentation you linked to, and the word "forever" doesn't appear in it. The closest it gets is the bit that you quoted, which says nothing about how long the class is kept, only that while the Class object exists, any objects created from it will reference the same "fixed location in memory" -- i.e. the same Class object. –  Daniel Pryden Feb 23 '10 at 20:26
add comment

Your Answer


