Home arrow static arrow Java Programming [Archive] - Freeing up Memory
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - Freeing up Memory
This topic has 7 replies on 1 page.

Registered: 10/8/03
Freeing up Memory  
Aug 3, 2004 11:52 AM


I am using mucho memory in my application and I was wondering what the best tactics for free up memory is. IE I have some JPanels that I only use once or twice... is there a way to erase them after their use is up? Any tips like that would help thanks!

Registered: 3/8/01
Re: Freeing up Memory  
Aug 3, 2004 11:59 AM (reply 1 of 7)

An object is automatically freed by Java after you're done using it, i.e. you don't have any more references to it. This is called "garbage collection". Java might decide to postpone this process for a while if there's lots of free space to garbage-collect several objects at once, so there are no strict guarantees other than that it'll never run out of memory. There's no other way to erase objects.

Thus, what you must do is make sure that you keep no references to objects you're done using. Usually this happens automatically with well-designed code, except if you're storing an object that you no longer need in a field or static variable or in an array. In this case, the best thing to do is to assign the value null to the object after you're done using it (theObject = null or array[x] = null;).

Registered: 8/3/04
Re: Freeing up Memory  
Aug 3, 2004 12:02 PM (reply 2 of 7)

As soon as an object isn't used anymore (it's out of scope, or no reference to it) the garbage collector will pass and free the memory for you.

If you start your JVM with the parameter -verbose:gc (e.g. java -vebose:gc myClass) the
garbage collector activity will be written to the console (stdout).

You can also give the JVM a little hint by calling System.gc() ( http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#gc() ), which gives the jvm the hint it should run the garbage collector ...

Registered: 8/15/02
Re: Freeing up Memory  
Aug 3, 2004 12:29 PM (reply 3 of 7)

As soon as an object isn't used anymore (it's out of
scope, or no reference to it) the garbage collector
will pass and free the memory for you.
Not quite. Once there are no refrences to an object it is eligible for gc. When the gc runs and whether it decides to clean a particular object on a sweep is out of your control. System.gc() is just a hint, if you app is busy I think that either the call is ignored or put on hold until a better time.

Registered: 5/3/01
Re: Freeing up Memory  
Aug 3, 2004 12:52 PM (reply 4 of 7)

Also, the GC is only "required" (not sure if this is in the specs or not) to run if an OutOfMemoryException will occur if it does not run before allocating another object; therefore, there is nothing to stop the JVM from using up all the memory that is available to it at any given time. As a matter of fact, it would make some sense for the JVM to use up as much memory as it is allowed (why else give it all the memory).

You can tell the JVM how much memory it is allowed to use when you start it (java -Xmx<size> allows you to set the max heap size)

Registered: 10/8/03
Re: Freeing up Memory  
Aug 3, 2004 1:08 PM (reply 5 of 7)

Thanks for all you input!

Registered: 00-11-29
Re: Freeing up Memory  
Aug 3, 2004 1:18 PM (reply 6 of 7)

In Swing, when you are done with a Window, you need to call dispose. If you don't do so it will never be garbage collected. These Objects are referenced by background wiki/./threads that you don't have direct access to. You have to tell the thread to release it's reference to the Window. This also releases any OS resources in use by the Window.

Registered: 8/4/03
Re: Freeing up Memory  
Aug 3, 2004 1:18 PM (reply 7 of 7)

Some things you might want to keep in mind;

1) Scope. As other posters have said, scope is one of the things that determines whether an instance can be collected. It's very important that you keep close track of the scoping of memory spaces in your application. I highly recommend reading the relevant sections of "Thinking in Java" by Bruce Eckel. The text is available online at ...


2) Dangling references. A dangling reference occurs when an instance is no longer needed for anything, but it's still in scope and it still has value.

The question to ask yourself in this regard is do I need to store this piece of information here.

3) Some things are more critical than others. For example, database connections can if left dangling can not only cause your app to bloat in terms of memory, but can easily bring the whold application to its knees.

PS's basic rules of thumb number 2, Make sure you clean up any instance before you exit the scope where it was initialized.


public class SpiffyClass {  private Connection connection ;  private Statement statement ;  private ResultSet resultSet ;   public SpiffyClass(){    super() ;  }   public void initConnection(){    // In here we would initialize the database connection the details don't really matter at this point.  }   public void build(){    String sql = "SELECT * FROM SOMETABLE"try{      initConnection() ;       if(! connection.isClosed()){        statement = connection.createStatement() ;        resultSet = statement.executeQuery(sql) ;         // do whatever other processing you need to do.  //         resultSet.close() ;        statement.close() ;        connection.close() ;      }    }    catch(SQLException e){        // don't forget to handle the exception    }    finally{      resultSet = null ;      statement = null ;      connection = null ;    }  }}

There are lots of variations on the theme, and this isn't the only case, or the only way. The point I'm trying to illustrate is that I initialize the database objects inside the build method, and before I leave that method I make sure that they are closed and in this case set to null so that no matter what if gc comes around it can release those objects. If I were going to be reusing that particular connection object over and over with a single active instance of the class, I might not set it to null until I destroyed the object so that I wouldn't have the cost of re-instantiating the object over and over again.

There is always more than one way to skin a cat in Java, but this rule has served me well over the years.

Your milage may of course vary.

This topic has 7 replies on 1 page.