How much memory will JVM Allocate to 1) Static String 2) Static Integer
I am exploring this issue as I am getting Heap Memory Out of Memory Exception, I have in my application 8 constants file and each file has almost near to 300 Static Constants.
Is that a good practice to declare all the constants as a Static or any other practice can I Follow?
2400 String constants will not run you out of memory. At a generous 10K each, that would be just 24MB. At the more usual rate of 100 bytes each, it is just 240K.
I would look for the memory hog somewhere else.
I assume these are both static and final since you are referring to them as constants.
If a primitive type or a string is defined as a constant and the value is known at compile time, the compiler replaces the constant name everywhere in the code with its value. This is called a compile-time constant. For primitive types no heap memory needs to be used. Strings are interned, and only one copy needs to be stored in heap.
Anyway I don't believe 8 x 300 strings are causing an out of memory condition. Your problem must be somewhere else.
How big are your constant strings?
The memory used by the strings is of the order of 8 * 300 * 2 * average-length = ~5k * average-length. It doesn't seem like enough to use all your memory.
It is indeed good practice to declare constants as static, and also final. e.g.
public static final String A_STRING = "this String is constant";
Note, it is the reference that is made constant by the 'final' modifier, not the object itself.
How much memory will JVM Allocate to 1) Static String 2) Static Integer
(To simplify things, I'll assume we are talking about a 32bit JVM. Also note that these numbers are approximate, and JVM specific.)
The easy one first - each static Integer variable occupies 4 bytes of memory for the reference plus 4 bytes + 1 object header (typically 8 bytes IIRC). Grand total - 16 bytes.
(And if you are talking about static int variables, it is 4 bytes total per int.)
A static String variable is a bit more complicated ... and more expensive:
String object has 4 x 4byte fields + 1 x 2 word object header: that's 24 bytes.(string.length() + 3) / 4 bytes for the content - that's 12 + some multiple of 4 bytes.Add that all up and you get (say) 80+ bytes per string, depending on string length. But nearly all of those bytes are the representation of the (interned) String itself. Only 4 bytes are due to the use of a static.
I am exploring this issue as I am getting Heap Memory Out of Memory Exception, I have in my application 8 constants file and each file has almost near to 300 Static Constants.
That's insignificant. The OOME is almost certainly due to something else.
Is that a good practice to declare all the constants as a Static or any other practice can I Follow?
It is good practice to declare real constants as statics, up to a point.
However, large numbers of constants in the source code gets unwieldy, and you eventually run into compilation errors due to limits in the format of a bytecode file. At that point (and probably well before then) you should move the constants out of your source code and into a database or configuration file.
You are likely to run into the bytecode-format-imposed limit well before memory usage becomes a significant issue.
How much space a string object takes depends, of course, on the length of the string.
Besides the characters of the string itself, a string contains a few control fields, but I count them as 28 bytes plus another embedded object (ObjectStreamField), I'm not sure how big that is, but anyway it's maybe a few dozen bytes. Each character takes 2 bytes. You need, I think, 8 bytes for the handle. If you're strings are, what, maybe 20 characters or so each?, maybe you have as much as 100 bytes per string. So like Thilo says, 2400 strings may sound like a lot but it's going to take hundreds of kB. Unless you're talking about Java embedded in a wristwatch or some such highly constrained environment, it's hard to imagine that this is going to be a significant factor in blowing your memory.