I'm a little bit confused why the key-Member has actually a very low
retained heap size and displays a different string than the char inside
the String which has an even bigger retained heap size. This can be seen
on every HashMap-Entry I checked from this map (it contains actually
>100.000 elements ;). Is there anything I'm doing wrong in my very simple
assumption that the key should be the same as the char inside it?
your observation results from the way how Strings are implemented/working.
Every String consists of a reference to a char. Additionally every
String contains a length and an offset where the actual String inside the
char starts. This way many Strings can 'share' one char... imagine all
the substring methods which return a new String pointing to the same
char with a different offset or a different length.
You can search for the incoming objects for one of the big char. I bet
you will find not only one but many Strings ;-)
thanks for the information! I checked a couple of char an yes, I found a
couple of String-objects that hold the char as value-reference. For
example I checked a char with a retained heap size of 63,968 bytes and
found two String-objects each with a count of 30.
Somehow this seems to me like a huge design problem of the sun jvm's, but
I think I'm overlooking something very important ;)
mea culpa! I just took a look into the source of String and noticed that
calls like substring() really keep the reference to the original char
and the rest is as you told me. I didn't know that fact and well, now I'm
going to be much more careful when using substring() if I know that I'll
keep the sub-string for a longer time.