If Java Strings are immutable and StringBuilder is mutable why they wasting same ammount of memory in my code?

Question

I ran those code and I got some questions, this kinda got wierd.

Using String:

while(true)
{
    String s = String.valueOf(System.currentTimeMillis());
    System.out.println(s);
    Thread.sleep(10);
}

Using StringBuilder:

StringBuilder s = null;
    while(true)
    {
        s = new StringBuilder();
        s.append(System.currentTimeInMillis());
        System.out.println(s);
        Thread.sleep(10);
    }

In both cases they get stuck in 12540 K waste of memory. Running this test on Windows XP SP2. So.. Why they wasting same ammount of memory? Why did immutable String stop wasting memory? Off: How can I convert StringBuilder to byte array encoded in a specific charset?

Answer 1

Because you are building and throwing. In fact, you are not really building any string using StringBuilder. Notice, you are instantiating a new StringBuilder object in every go.

Answer 2

It is hard to figure out what you are actually asking here, but the application is behaving exactly as I would expect.

Strings are immutable and the garbage collector doesn't take them out. isn't it

Both mutable and immutable objects may be garbage collected in Java.

The actual criterion that determines whether an object is actually garbage collected is it reachability. In simple terms, when the garbage collector figures out that the application can no longer use an object, the object will be deleted.

In both of your applications, objects of roughly the same size are being created once every 10 milliseconds. In each iteration, a new object is being created and its reference is being assigned to s, replacing the previous reference. This makes the previous object unreachable, and eligible for garbage collection. At some point, the Java VM decides to run the garbage collector. This gets rid of all of the unreachable object ... and the application continues.

I read that common Strings are not collected ever by the garbage collector, is that false?

This is false on two counts:

• Strings created by new String(...), String.substring(...) and so on are no different from any other Java object.

• Strings that are interned (by calling String.intern()) are stored in the string pool which is held in the PermGen heap. However, even the PermGen heap is garbage collected, albeit on longer timescales that the heap in which objects are normally created.

(Once upon a time, the PermGen heap was not garbage collected, but that was changed a long time ago.)

Answer 3

1. You seem to assume that a mutable class would waste more memory than a non-mutable class. I don't understand why.

2. Your code is wrong, if it's intended to allocate more memory in each loop. It just assigns the s reference to a new object, hence the previous one is lost and will be garbage collected eventually.

3. To look at the OS memory for the JVM is a very rough/imprecise estimation of the Java allocated memory.

4. StringBuilder and String (and StringBuffer and char[] ) are all efficient, they allocate approximately 2 bytes per char (Java uses some UTF-16 variation) plus a small (negligible for big strings) overhead.

Answer 4

You are confusing two very different things:

• Strings are immutable, but this has nothing to do with whether or not they are garbage collected. However, it means that if you need to make a lot of changes to a String (such as building a big string by appending one character at a time), then you end up making lots of copies and a lot of work for the garbage collector.
• String literals (i.e. Strings that are written directly in the source code) are part of a pool of interned Strings and generally not garbage collected. However, this is done in order to allow multiple instances of the same String in the source code to be replaced by references to the same object, which can save a lot of space. And this is only possible because Strings are immutable, so two parts of the program holding a reference to the same String cannot interfere with each other.

Answer 5

As already explained, since you are not mutating the string but rather just pointing s to a new value; the old value has to be garbage collected. Here is a snippet using stringBuffer to try to actually mutate the value s is pointing to.

StringBuffer s = new StringBuffer();
    while(true)
    {
        s.replace(0,13,Long.toString(System.currentTimeMillis()));
        System.out.println(s);
        Thread.sleep(10);
    }

It should be noted that this doesn't solve the problem because of two things. First of all we have to make a new String everytime using Long.toString(), and secondly since s.toString() will be called; this will make a new String sharing the value of stringBuffer (atleast this was the case last time I checked). When we do s.replace it will allocate a new array to hold this new string in order to preserve the unmutability of the String.

Actually, In this trivial case, the best you can do (as far as I know) is:

while(true)
    {
        System.out.println(Long.toString(System.currentTimeMillis()));
        Thread.sleep(10);
    }

Answer 6

Wanted to post this as a reply to Stephen C, but for some reason I can't; so here is a point of clarification...

String.subString(...) does NOT create a new String. It references a point within an existing String, and returning substring values is one sure way to introduce memory leaks into your app (especially if building a list of Strings based on substring values of another list of strings).

Best practice in this case is:

return new String(s.subString(...));