This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
If one of your classes contains a static reference to an object, this object will not be garbage collected until your class is unloaded.
If your class was loaded by the bootstrap classloader this in unlikely to happen until your program finishes. If it was loaded by a CustomClassLoader, then the variables will be subject to GC when the classloader is garbage collected.
Therefore, I would say that yes, you have to be careful with the objects you put as static references in a class.
It is important, then, to set clear that because a variable is static it does not mean the object it references is treated in a different way than other objects. If you consider that one of your static variables is referencing an object you no longer need, then set static variable to null so that the object can be garbage collected. Otherwise you would be preventing the object from being disposed, consuming precious bytes in the system memory. [ October 19, 2006: Message edited by: Edwin Dalorzo ]
Originally posted by Tony Keith: in page 191 point one, there is a statement (I know it's true), that saying static variables (and methods) will stay loaded in JVM.
my question is from design prespective (including singleton pattern), is it a good design? should we use static with caution? because static will eat memory imo.
Yes, but not because they will "eat memory". Personally I think static variables have a very small place in Java, they shouldn't be used often because it's not often that it's "good" to use them. Consequently I would think that if you're having memory problems due to static variables the design is bad to begin with and that's a larger issue, the memory problem is just a side effect.
When it comes to a "Singleton" I suppose that depends on what you want from it. Is it a single instance per classloader or just one instance at any given time? In the case of the former you can use a WeakReference so that the object can still be collected. Then you just check to see if it still exists and if not, create a new one to return and keep a WeakReference to it. Of course, now we're probably not really talking about a "Singleton" anymore, but the definition of one, especially in Java isn't very well defined in the first place. If you want to hold on to one reference and only one reference per classloader then by it's very nature it's going to have to be held onto for the life of that classloader. This really shouldn't be a problem though, Singleton's are rarely (if ever) appropriate and thus shouldn't be taking up too much memory.
And as an aside, static methods won't take any more or less memory than non-static methods. The methods byte code is loaded once the class is loaded, and the methods stack memory only lives for a method call, no matter whether it's static or not.
Still I agree with Ken that having a lot of static methods is a design smell for other reasons - it's an indicator for an overly procedural design (which makes the code more rigid than necessary).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus