Don’t get tangled

The state of String in Java


Over the past year, how Strings are represented in Java has changed. Attila Balazs outlines what’s new, and shows you how you can perfect your code for it.

the past year there have been a couple of changes in how Strings
are represented in Java. In this post, I will summarize these
changes, help you understand how it can influence the performance
of your code, and give you a couple of ideas for tuning your

Java 7 update 6 (1.7.0_06)


Up until
Java 7u6 the String class had four instance fields:

  • value – this was a reference to a character
    array (char[]) containing the actual characters which make up the
    String (remember that char in Java is 16 bit/two bytes wide
    unsigned integer type).
  • offset – an integer specifying the index of the
    first character belonging to the string in the array. This was 0
    most of the time.
  • count – an integer specifying the number of
    characters belonging to the string (the length of the
  • hash – an integer representing the hash code of
    the String. This was being lazily populated and had some tricky
    logic applied to it (it wasn’t volatile but still was thread safe
    because the Java Memory Model guarantees the atomicity of 32 bit
    reads / writes. It also had an issue with strings that had hashCode
    zero – in this case it was being recalculated needlessly because 0
    was being used as a marker for “not yet calculated”)

This representation meant that creating a substring of an
existing string was a rather cheap operation (since the actual
characters weren’t being copied – just a new reference to the
existing backing array was created). In fact this was the reason
why this implementation was chosen – for Java to perform well in
situations where a lot of substrings of larger strings were created
(for example when parsing source code, CSV files or other text
The danger of this representation is that you
can retain more memory than you actually need:

String str = get100MBFile();
str = str.substring(0, 10);

the above code we’re retaining 100MB of memory, even though we only
need ten characters. The solution is to force the copying of the
underlying char array by using the String(String)

str = new String(str);

can pretty quickly diagnose this situation if you know what you’re
looking for. Also, some profilers have dedicated diagnostic tools
which detects such problems.

issue which arises frequently in practice when working with strings
is Java are duplicate strings – distinct instances of String which
contain the same sequence of characters. While strings are
immutable and instances can be freely interchanged (or deduplicated
to reduce memory consumption), Java only does deduplication for
String constants.

This is wholly understandable since doing deduplication
for all strings would be very time consuming and it would slow down
the program without much benefit (in the general case).

Still, if we know that our dataset contains a lot of
repeating strings, we can reduce the memory footprint by
deduplicating our strings manually.

One way to do this is to call intern on the String
This returns an identical string from
the internal string pool (if one was already present there) or adds
the current string to the internal string pool and returns it.
There were a couple of issues with intern however in the pre-Java 7
days which discouraged its use:

  • it was slow. Very slow.
  • the string pool was located in a special memory
    area (the PermGen – permanent generation – space) which wasn’t
    being affected by the “maximum memory” (-Xmx) command line switch
    and had to be tuned separately using the -XX:MaxPermSize=… switch
    (or risk running out of it).

In conclusion if you needed deduplication under Java
1.7.0_05 and earlier, it was best if you rolled your own solution
using WeakHashMap<String, WeakReference<String>>. Even
better, if you knew all the possible values you can have before
hand, you could use an Enum to represent your data.

Java 7 update 6



Starting in Java 7u6 Oracle went back to the
simpler representation of String. It now contains only 3 instance

  • value - as before, the actual

  • hash - the cached hash code of the
    String (calculated lazily, still with the same issues for Strings
    with a zero hash code)

  • hash32 - a new hash code based on
    Murmur hash, which gives a better dispersion of hash

A couple more words about the alternative hash

  • it isn’t exposed publicly through the String
    class. You can access it using the (unofficial)

    sun.misc.Hashing.stringHash32 method

  • unlike the original hash code,
    hash32 for two strings containing the same
    characters but running in different JVMs (on the same machine or on
    different machines) isn’t guaranteed to be the same (in fact most
    likely it won’t be, since a
    HASHING_SEED” value is included in the
    calculation which is initialized on JVM startup using the current

  • the purpose of alternative hash code is to give
    better performance for HashMap and related classes with String keys
    and to thwart hash-collision denial of service attacks

  • Its usage isn’t enabled by default. You need to
    set the “
    property to enable it. If you set this to a value X, then HashMap
    and related classes with a capacity at least X will use the
    alternative hashing algorithm.

  • A word of caution if you want to enable
    alternative hashing: prior to Java 7u40 (ie. all versions between
    Java 7u6 and Java 7u39) had a performance issue which meant that
    HashMap creation while alternative hashing was enabled was slower
    than needed to be. Thus if you want to enable alternative hashing,
    ensure that you have the latest Java 7 runtime.

As you can see substring works now “as
expected”, creating a completely independent copy of the requested
characters. This eliminates the possible memory retention issues
from the previous versions.

This new behavior can cause performance
regressions in some special cases when we have a large string and
extract many substrings from it. A canonical example for this is
parsing of source code (or any other text for that matter) where we
create a substring for each token. You can find a possible solution
for this a little bit later on in this post.

Yet another change which was made in Java 7 was
the removal of compressed strings. The compressed string option
allowed for a more compact representation of strings (using

byte[] instead of char[]
- 50% less memory needed) which contained only ASCII
characters (as is the case in English environments).

In practice the memory savings were 10-30% and
the additional code complexity was not deemed justifiable. Again,
read on for a possible solution.


In Java 7 the string pool used by the
intern call was relocated to the heap. This
means that setting the maximum memory size will also make it
possible to have a larger string pool. Its performance was also
improved which means that we can get rid of our manual string

If you have an application which uses
intern for string deduplication, take a look at
-XX:StringTableSize=… tuning
parameter. This determines the number of “buckets” the hash table
containing the strings has. By default this is

1009 in Java 7, which is insufficient when we
have many interned strings. You might want to tune it to something
60013 (come Java 8 this will be the
new default value).

You can also use the
-XX:+PrintStringTableStatistics option which
prints out a statistic about the string cache to the console during
shutdown and the
jmap tool which shows
the total number of strings in the string cache.

Tuning for many substrings

If you are in one of those special situations
where you need a lot of relatively long-lived substrings from a
single source (like parsing source code or other large text files),
you can create a custom
implementation which mimics the old substring behavior (and
also uses
byte[] if you know that you’re
only dealing with ASCII data for example).

CharSequence is an interface
introduced in Java 1.4 to work-around the fact that the String
class is final and we can’t have alternative implementations.
String itself implements
CharSequence (as
StringBuilder) and if you wish to
have a flexible API, you should expect

CharSequence for parameters rather than

In our benchmark code we provide an alternative
implementation for CharSequence (BBCS – which stands for
BlobBackedCharSequence) that uses a byte array to store characters
(thus being space efficient if we only use ASCII characters) and
uses the “cheap substring” trick from Java 6. You can find the
source code under my GitHub account.

Lets see what this would look like:


The benchmark does a pseudo-tokenizing of the JDK 8
source code (you can get early access builds of JDK 8 here to
test your code now) and reports the runtime and the consumed

The benchmark supports different implementations
for extracting the String tokens:

  • null – this is used to create a baseline (to see
    how much the Token instances occupy)

  • String – uses String.substring

  • for Java 6 we also test String with compressed
    strings enabled

  • cached String – uses a simple opportunistic
    cache (ie. it doesn’t guarantee that all the duplicates are
    detected, but it’s fast)

  • interned String – uses String.intern as a

  • Blob – uses the custom CharSequence

  • cached Blob – the custom CharSequence
    implementation combined with opportunistic caching

Tests were run with both Java 6 and Java 7. The results

Java Version Tokenizer
memory (MB)
null (baseline) 285  


String 639
Chached String
Interned String 291
Compressed String 461
Blob 508
Cached Blob 375
null (baseline) 279  
String 618
Cached String 328
Interned String 304
Blob 507
Cached Blob 375


usual, the most important advice is: use an up-to-date version of
the JVM. Version 6 is end of lifed and you should be using Java 7,
and testing with the pre-release versions of Java 8. There can be
performance regressions but they are very rare and as a general
rule of thumb you should see a 10% improvement in CPU and memory
usage by upgrading from version 6 to version 7.

As for the String representations:

  • to see performance regressions you would need to
    have some very particular data and processing requirements (lots of
    data with very varied parts – which makes caching ineffective – and
    which needs to be processed in one chunk – ie. you can’t process it
    line-by-line for some reason)

  • if the performance / memory usage is not within
    expected bounds, the first step should be to see if the right data
    types are use (ie. don’t keep numbers / dates as strings, if a
    field can have only a limited number of values, use an

  • String interning has improved dramatically in
    Java 7. Use it if you have a lot of duplicate strings. Also, look
    at the tuning options / statistics exposed related to string table
    and try adjusting them.

  • more complex solutions (like
    BlobBackedCharSequence) can be implemented, however the gains might
    not be as great as expected. Use this approach only if the other
    options are exhausted and they didn’t provide satisfactory gains,
    and only after careful benchmarking, to avoid making the situation
    worse on a whim.

You can read more from Attila

GitHub: https;//
comments powered by Disqus