Benefit to making objects static, even though they don't need to be?

Question

I have many programs that declare objects at the top my class. This object will only be modified from within its own class, and there will never be more than one instance of this class running at the same time. Is there any benefit to declaring the objects as static?

public class MyClass {

    private Map<String, Object> myMap; // any reason to make this static?

    // constructor and other code here
}

This could depend on things such as when/how the object should be initialized, the thread-safety of the class, etc. — David, Jul 27 '13 at 00:00
it won't make any performance improvement. [look this other post](http://stackoverflow.com/questions/3805155/are-java-static-calls-more-or-less-expensive-than-non-static-calls) — Diego D, Jul 27 '13 at 00:04
There are lots of reasons not to make it static. You should almost never use static variables unless you have only static methods. Wich again is something you should avoid in most cases. `static` is also the the main reasons for mem leaks. — zapl, Jul 27 '13 at 00:05
@DiegoD - that post is about static methods rather than static fields. — Stephen C, Jul 27 '13 at 00:10
@DiegoD - If it's a complex, read-only object then making it static so it's only constructed _once_ could definitely have better performance than constructing a new one each time you create a new instance of `MyClass`. — DaoWen, Jul 27 '13 at 00:19

score 1 · Answer 1 · edited Jul 27 '13 at 00:08

1

Declaring Variables as static makes the variable shared among all objects of the class ( in your example MyClass) another thing that you can make static methods that return the variable without creating an object of the class

MyClass.method();

sometimes this makes more sense than create an object of MyClass then call the Method, like the Math class one side issue: if you want to have only one instance of MyClass, checkout Singleton Design Pattern which insure only on instance of the class

edited Jul 27 '13 at 00:08

Bhushan

18,329
31
104
137

answered Jul 27 '13 at 00:00

Moayad Al-sowayegh

87
1
9

Yes, I know what `static` means for scope and instances, and I already do use a `getSingleton()` method for many of my classes. I'm more concerned about the performance implications. Thanks for the feedback :) – BLuFeNiX Jul 27 '13 at 00:38

score 1 · Answer 2 · answered Jul 27 '13 at 00:25

The one reason for making members static is constants. public static final Sting SOME_CONSTANT = "amazing"; is way easier to access statically than though an instance.

Reasons to not use static members is testing (how to easily mock a static member?) or (specifically with a map) thread safity.

Stephen C · Accepted Answer · 2013-07-27T02:07:28.463

0

Is there any benefit to declaring the objects as static?

Not really, no.

Certainly, there is no performance benefit. This is because statics are actually stored in (hidden) static frame objects that live in the heap. Ultimately, the JIT will generate native code for fetching a static variable that is no faster than an object variable fetch.

You could argue that it is more convenient to use a static to share some data structure "globally" within an application. But that convenience has some significant disadvantages. The biggest ones are that statics make testing harder, and they make code reuse harder.

However, you shouldn't confuse the general case with the specific case where the static holds or refers to an immutable value or data structure; e.g. like a String constant or a constant mapping. These can be justified on both design and practical grounds; e.g.

  public static final String THE_ANSWER = "Forty two";

  private static final Map<String, Integer> SCORES;
  static {
      Map<String, Integer> map = new HashMap<>();
      tmp.put("perfect", 100);
      tmp.put("average", 50);
      tmp.put("fail", 20);
      SCORE = Collections.unmodifiableMap(map);
  }

This is fine ... so long as there is no possibility that different (current or future) use-cases require different values / mappings / whatever. If that is a possibility, then static could be harmful.

edited Jul 27 '13 at 02:07

answered Jul 27 '13 at 00:01

Stephen C

698,415
94
811
1,216

If the object in question is a complex, read-only object then making it static so it's only constructed once could definitely have better performance than constructing a new one each time you create a new instance of `MyClass`. This is basically an optimization question asking *"Do I really need **N** copies or could I get by with just 1?"* I can't think of any cases where this would make sense for non-read-only objects though. – DaoWen Jul 27 '13 at 00:21
@DaoWen - but that is NOT what we are talking about. The example is a *non-final* variable, and the Question *explicitly* states that the object it points to *will* be modified. – Stephen C Jul 27 '13 at 01:49
You're totally right—I just wanted to point out that as the only use case I can think of where it _would_ be useful to make a field static. – DaoWen Jul 27 '13 at 02:14
'(Hidden) static frame objects that live in the heap' is a contradiction in terms surely? Stack frames are in the stack, heap objects are in the heap. – user207421 Jul 27 '13 at 02:17
@EJP - I'm NOT talking about stack frames. I'm talking about the (permgen I think) heap objects that hold the static variables for each class. – Stephen C Jul 27 '13 at 02:48

Benefit to making objects static, even though they don't need to be?

3 Answers3