How much time a java class resides in memory

Question

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 ??

Answer 1

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

Answer 2

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

They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory

Answer 3

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

Answer 4

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).