Java high amount of char[], how to reduce?

Question

I believe this garbage is created when I call new String in various places throughout my application. How can I "create" a string without making a new object each time?

The reason for being this garbage-sensitive is because my application cannot create garbage as we need to run close to real-time with the default Java GC.

// you can see I use the same chars array
public String getB37String() {
    long l = getLong();
    int i = 0;
    while (l != 0L) {
        long l1 = l;
        l /= 37L;
        chars[11 - i++] = validChars[(int) (l1 - l * 37L)];
    }
    return new String(chars, 12 - i, i);
}

And for example using StringBuilder.toString() which uses new String underneath.

// and you can see that I use the same builder
public String getString() {
    builder.delete(0, builder.length());
    char ascii;
    while (0 != (ascii = (char) getUByte()) && backing.hasRemaining())
        builder.append(ascii);
    return builder.toString();
}

Answer 1

First an observation:

The reason for being this garbage-sensitive is because my application cannot create garbage as we need to run close to real-time with the default Java GC.

If that ("cannot create garbage") is actually a true statement¹, then you may well have started in the wrong place by picking Java as your implementation language.

Java is designed on the assumption that generation of garbage is OK. It is the "cost" of avoiding the inherent complexity (and consequent bugs) of doing explicit memory management This assumption pervades the language design and the standard library design.

The other thing about Java that is not "in your favour" is that it strongly supports good OO design principles. In particular, with few exceptions, the the APIs provide strong abstraction and are designed to prevent traps where an applications could accidentally break things.

For example, when you do this:

  char[] c = new char[]{'a', 'b', 'c'};
  ...
  String s = new String(c);

the String constructor allocates a new char[] and copies to the characters in c to it. Why? Because if it didn't, you would have a "leaky abstraction". Someone could do this:

  char[] c = new char[]{'a', 'b', 'c'};
  ...
  String s = new String(c);
  ...
  c[0] = 'd';

and the leaky abstraction has resulted in a change to a (supposedly) immutable object.

---

So what is "the solution"?

1. You could rewrite your application in C or C++ or some other programming language where you can have complete control over memory allocation. (Of course, that is a lot of work ... and there may be other reasons why you can't do this.)

2. You could redesign the relevant parts of your application so that they don't use String or StringBuilder or any of the standard Java classes that involve explicit or implicit (under the hood) heap allocation. It is not impossible, but it is a lot of work. For example, many standard and third-party APIs expect you to pass them String objects as parameters.

3. You could analyse the parts of your code that do string operations to do it "smarter" in order to reduce allocation of garbage.

Unfortunately, all of these things are likely to make your code-base larger, harder to read, harder to debug and harder to maintain.

---

^{1 - One case where it might not be true is if the problem you are really trying to solve is GC pauses. There are ways to address GC pauses that don't go as far as not creating any garbage. For example, picking a low-pause parallel GC, and reducing the size of the young generation space, could give you pauses that are short enough to not be noticeable. Another trick is to force a GC at points when you know that the user won't notice; e.g. when loading a new level in a game.}

Answer 2

Difference Between Both

The reference is here.

They both are the same, they are like any other object but:

Since String is one of the most used type in any application, Java designer took a step further to optimize uses of this class. That's why they come up with an idea to cache all String instances created inside double quotes e.g. "Java". These double quoted literal is known as String literal and the cache which stored these String instances are known as as String pool.

At high level both are String object, but main difference comes from the point that new() operator always creates a new String object. Also when you create String using literal they are interned.

String a = "Java";
String b = "Java";
System.out.println(a == b);  // True

Here two different objects are created and they have different references:

String c = new String("Java");
String d = new String("Java");
System.out.println(c == d);  // False

Similarly when you compare a String literal with an String object created using new() operator using == operator, it will return false, as shown below :

String e = "JDK";
String f =  new String("JDK");
System.out.println(e == f);  // False

Garbage Collectors

The reference is here.

In fact the String objects that correspond to String literals typically are not candidates for garbage collection. This is because there is an implicit reference to the string object in the code of every method that uses the literal. This means that the String is reachable for as long as the method could be executed.

However, this is not always the case. If the literal was defined in a class that was dynamically loaded (e.g. using Class.forName(...)), then it is possible to arrange that the class is unloaded. If that happens, then the String object for the literal will be unreachable, and will be reclaimed when the heap containing the interned String gets GC'ed.

String Pool

The refrence is here.

java.lang.String.intern() returns an interned String, that is, one that has an entry in the global String pool. If the String is not already in the global String pool, then it will be added.

Programmatically you can follow this approach:

1. It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.

So if you use intern() on a String:

2. By calling String.intern()

Then:

3. Is guaranteed to be from a pool of unique strings.

Answer 3

If you're using Java8u20 or newer you can try using -XX:+UseG1GC -XX:+UseStringDeduplication to enable string deduplication.

While this won't avoid the creation of garbage it might reduce memory pressure.

---

If you really want to create String instances without the copying cost of the char[] array you will have to access the package-private constructor java.lang.String.String(char[], boolean) or the private char[] value field via reflection, with the appropriate runtime checks/error reporting whether it actually works.

I wouldn't recommend it, but it's an option.

---

Another option is to stop using Strings and work with ByteBuffer. You can slice them as needed, return views, return read-only views, recycle them.

And they're also more compact if you work with utf-8 data. The downside is that you can't use APIs that require Strings.

Or just deal in CharSequence/StringBuilder/Charbuffer objects in as many places as you can.

---

Depending on use-cases you can also create a string cache for your computation. Map<T, String> where T is the input parameter of your computation. This way you will only ever need 1 String for each possible value of T.

---

return new String(chars, 12 - i, i);

Note that as of Java 8 strings do not store an internal offset, i.e. String objects are not a "view" on some potentially larger backing char array.

This used to be different in the past, but since it was an implementation detail it got changed.

It might be possible to undo that change with a custom String class added via the bootstrap classloader, but that's more likely to break or cause severe performance degradation than not.

---

as we need to run close to real-time with the default Java GC.

This may be your actual problem.

None of collectors configured by default provide you anything that comes even close to realtime behavior. CMS or G1 can provide much lower pause times, especially on large heaps, than either the Serial or ParallelOld collectors.