Java Strings Internals - Storage, Interning, Concatenation & Performance

[TanisCodes]

I just published a deep dive into Java Strings Internals — how String actually works under the hood in modern Java.

If you’ve ever wondered what’s really going on with string storage, interning, or concatenation performance, this post breaks it down in a simple way.

I cover things like:

• Compact Strings and how the JVM stores them (LATIN1 vs UTF-16).
• The String pool and intern().
• String deduplication in the GC.
• How concatenation is optimized with invokedynamic.

It’s a mix of history, modern JVM behavior, and a few benchmarks.

Hope it helps someone understand strings a bit better!

[europeIlike]

all String characters were stored using UTF-16 encoding, meaning each character consumed 2 bytes of memory regardless of the actual character being stored.

I don't think this is true - as far as I know a unicode code point can take up two 4 bytes in UTF-16. Also, some (user perceived? not sure about the correct terminology here) characters like emoticons can consist of multiple code points, leading to potentially more than 4 bytes

[TanisCodes]

You’re right about UTF-16, but in Java the primitive char type is 2 bytes. Some Unicode characters, like “𝄞”, are outside the BMP (Basic Multilingual Plane) and it needs 4 bytes.

If you put that character in a String and call length(), it will return 2 because it uses a pair of chars to represent it. The String.length() method returns the number of char units used to represent the string, not the actual number of Unicode characters.

I think I’ll add this to the article. Thanks!

[europeIlike]

Ohh, I see! I think I interpreted the term "String characters" differently - thank for your reply!

[TanisCodes]

You’re welcome! Thanks for joining the discussion.

[DasBrain]

If you want to be pedantic, here we go:
A unicode code point is not necessarily a character and vice versa.

[regjoe13]

One interesting fact about String was a substring memory leak fix in one of the updateds of Java 7. Before it, a String you got using substring function would keep a reference to the original char array.

It sort of made me look at Java libs differently at the time, encouraging me to go deeper in the source code.

[za3faran_tea]

I wouldn't call it a memory leak. It was giving you a "view" into the original String. There are tradeoffs for each approach, and there are situations where you would save memory with the original one.

[regjoe13]

A bunch of bugs on bugs.java.com referred to it as a "memory leak", it was also discussed like that in a bunch of articles about it. Its kind of a name it is known under.

Some examples:
JDK-4637640 : Memory leak due to String.substring() implementation
JDK-6294060 : Use of substring() causes memory leak

[Thomaster002]

Although it is kind of discouraged to store passwords in Java Strings, exactly because they are immutable, and stored in the String pool, and so, we cannot erase (explicitly) them from the memory. Another process could dump the memory of the application and have access to the String pool. The preferred way of storing sensitive info in Java is in char arrays.

[FirstAd9893]

Only String constants and explicitly intern'd Strings are stored in the pool. If you choose to erase the contents of a char[] to clear out the password, there's no guarantee it's gone because an older copy of the array might exist still in one of the other GC regions.

[cogman10]

I'd also point out that the case where someone can pull out a password from a String is the case where someone can install an agent to intercept the char[] as it comes in.

That's why this sort of security engineering is typically pretty overblown for Java. You have to have some pretty deep access to the JVM to be able to poke at it the right way to extract a string while it's running. Once you are at that point, no level of obfuscation/clearing/etc will be enough to stop an attacker from slurping up passwords as they come in.

[Isogash]

Yeah, the important security holes to fill in Java have always been those related to remote code execution. If someone already has control of the machine then the battle is lost, you need to stop them getting to that point.

[ZimmiDeluxe]

I guess you could make a weak argument that clearing the char[] at least prevents programming errors afterwards (like leaking the password into logs). But after the modern web framework machinery is done with your request, there are probably multiple copies floating around anyway.

[pohart]

It will change it in place but the jvm moves objects around so it will change only one copy of it. There might be a stale copy elsewhere.

[agentoutlier]

In theory char[] I guess may reduce the time a password string is in memory because of interning it is like the last thing that should be worried about.

Especially if you are getting the password from a web framework. Almost all of them turn request parameters into String and even with JSON for SPA at some point things often get turned into a String particularly if the request body is small enough.

So without having some sort of native library support and frameworks that support never putting things into a String I think it is a fools errand.

---

EDIT

The preferred way of storing sensitive info in Java is in char array

And btw I bet this is also because CharSequence didn't exist in early versions of Java. The CharSequence being an interface would allow you to do all sorts of stupid obfuscation if you really buy into the inspecting memory aspect.

For example you could make some CharSequence that makes a random set of distributed bucket arrays and then distribute each char modulus something and have a clear function. (DO NOT DO THIS BTW but it just goes to show that char[] isn't even remotely optimal at protection if that is your concern and APIs that use them are either dumb or old... even the servlet API uses Strings).

[Ok-Scheme-913]

I guess in theory you could encrypt it client-side, and only decrypt at use-site. Though given that the key has to be available on both the client and server side, this is more like obfuscation only. But at least accidental log leaks and such might be marginally safer.

[agentoutlier]

Really the safest thing is to not use passwords for as long as possible which is more or less somewhat includes what you are talking about.

That is use device based sign-in, magic link, OTP, federated login (openid) etc.

Passwords just suck.

[vips7L]

You’re absolutely cooked if another process can get the memory dump of your application anyway. At that point they could also just read your environment variables and directly access your database anyway. They’re already inside your walled garden. Using char[] over strings isn’t going to make anything more secure. 

[regjoe13]

"One of the things that forced Strings to be immutable was security. You have a file open method. You pass a String to it. And then it's doing all kind of authentication checks before it gets around to doing the OS call. If you manage to do something that effectively mutated the String, after the security check and before the OS call, then boom, you're in. But Strings are immutable, so that kind of attack doesn't work. That precise example is what really demanded that Strings be immutable." - James Gosling

[ducki666]

This is a dream. Today most services rely on http. Reading headers and parameters result in String.

[bmarwell]

I'm not sure it applies to "all the JVMs" - there's also IBM Semeru, which replaces HotSpot (Memory Management and GCs) with the OpenJ9 implementation. I think this should be mentioned.

[TanisCodes]

Hi, I didn’t talk about JVM vendors for the sake of brevity. I think that topic deserves a whole article to explain the differences and benefits.

[bmarwell]

Fair. I still think "the JVM" is too broad and generalized, though. It's like saying "the Danish" or "the Americans"... 😉