Is using Static better to memory management or not?

Question

In some articles and tutorials about static like this and this, it is said that using static is good for memory management, since static variable gets memory only once in class area at the time of class loading.

But my friend told me static methods are kept in stack and because managing heap is easier than stack and garbage collector works only on heap and as long as the application is running stack wouldn't get cleaned, try to use static methods less as much as you can.

NOTE:

I've read same questions in stackoverflow about stack memory but I didn't get much of it, because they are some how complicated and professional using "PermGen space" and other words I don't know.

I want someone simply explain if my friend advance is correct or not?

And I know it depends, imagine that I can design both with static or without static methods. memory management talking which one would be the better way?

Answer 1

The answer is: asking this question means that you spend your time and energy in the wrong place.

The key role to get to Java applications that perform well: come up with an elegant OOP design that implements your requirements in a straight forward way.

You have to understand that "Java performance magic" happens almost completely at run time by the workings of the Just-in-Time compiler. And the JIT is best at those commonly used patterns that we regard "best practices" in Java.

Trying to come up with "special" ideas like "lets use static all over the place" might even result in worse performance in the end - because your "special" code prevents the JIT from doing its job in the best way.

So: trust the JIT respectively the GC. And make sure that these tools can work in an "optimal" way by doing ... what everybody else is doing!

Don't let such thoughts of premature optimization ruin your OOP design. And even if your application would fall into that rare category that requires intensive low level optimization - then there is only one way for you: to study the workings of GC and JIT in depth.

In other words: such problems aren't real problems. Meaning:

• of course you avoid outright stupid mistakes BUT
• you otherwise do not worry about memory or performance topics unless you have a real issue at hand (for example with applications requiring too much memory or customers complaining to you).

And then - when you run into a "real" issue: then you have to profile your application to understand the root cause of the problem. Again: you do not allow for such premature (uneducated) optimization thoughts to affect your design in a negative way.

And as the comment implies that I wasn't clear enough: when you have a real memory problem, then you absolutely have to understand terms like "perm generation". Because then you have to understand in detail how the GC works. Seriously: believe the people here telling you that the static keyword doesn't play any significant role in creating "memory efficient" applications.

Answer 2

Memory allocation for static variables occur only once when program runs for first time. If you are using it in a class ,then only one instance is created which is shared by every object of the class. so memory consumption is less.Before java8 Static methods and variables are stored in the PERMGEN space.But now they have introduced new memory space called METASPACE now this is the place where all class methods,fields of class and constant pool are stored. For more details on METASPACE please visit:"https://dzone.com/articles/java-8-permgen-metaspace"

Answer 3

The short answer is you're friend is wrong. The class objects themselves (i.e. instances of java.lang.Class<T> are not allocated on a stack. Java loads classes as it goes along and doesn't unload them at the end of the function that loaded them so can't go on the stack. Also all threads access the same class objects but each has its own stack space.

Warning: The rest of this answer talks about JVM implementation details and garbage collection memory management. Most applications do not need to take these facts into consideration and must not rely on them for program correctness as they can and do change from release to release.

Many modern JVMs use a generational garbage collector and because system loaded classes won't be unloaded can put them in an area called the 'Permanent Generation' (PermGen) that is replaced in Java 8 by Oracle to be replaced with MetaSpace which holds the class meta-data the question refers to. But do recognise these are implementation details of The Oracle JVM and not part of the Java Specification.

The other possible confusion is that this all applies to the space required directly by the class and it's static references but not what those references refer to.

class Sample {
    private static BigThing biggie=new BigThing(10000);
}

In the example the object biggie references will be created on the heap like anything else. Indeed it isn't declared final here and could refer to any object created at any point in execution because it can be reassigned.

Here is a relatively recent article on the topic:

https://blogs.oracle.com/poonam/about-g1-garbage-collector,-permanent-generation-and-metaspace

Please note this area of the JVM has been subject to change and tuning over the years but (as far as I know) unchanged in Java 9.