Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

static var/method and JVM

 
Anthony Karta
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are a little beyond the scope of SCJP with this question. Moving to Java In General (Intermediate)...
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic