Strings
Everything about String: immutability and the literal pool, comparison, building strings efficiently, the common API, text blocks, and compact-string storage. Strings are the single most-asked non-collection Java class in interviews.
part ofJavaoverview, primer and where to startread it →on this pageshowhide
explore
- String Immutability5 questions
- String Literal Pool and intern()4 questions
- equals() vs == for Strings4 questions
- String Concatenation5 questions
- StringBuilder vs StringBuffer5 questions
- Common String API Methods6 questions
- Text Blocks4 questions
- String Internal Representation5 questions
questions
page 2 of 2Given the UTF-16-based String API, what subtle bugs arise from char-based operations on text with supplementary characters, and how do you handle them correctly?
basics
~20 sA Java char is one UTF-16 unit, but some characters (like many emoji) need two chars (a surrogate pair). So length() and charAt() count units, not real characters, and slicing or counting by char can split a character in half. Use code-point methods or codePoints() for correctness.
What are the memory implications of String's internal representation, including object overhead and the savings from compact strings?
basics
~20 sA String costs more than just its text: the String object header, fields, and the separate backing array each have memory overhead. Compact strings cut the text bytes roughly in half for ASCII, but very short strings are dominated by fixed per-object overhead.
Which string expressions get pooled at compile time, and why does "a"+"b" == "ab" but s+"b" (with s a variable) does not?
basics
~20 sThe compiler folds expressions made only of constants (literals and final constants) into a single literal, which gets pooled. So "a"+"b" becomes "ab" at compile time and equals the pooled "ab". But if a variable is involved, the join happens at runtime and produces a fresh, un-pooled object.
Are text blocks fully interchangeable with regular String literals, and what subtle pitfalls exist?
basics
~20 sYes — a text block compiles to an ordinary String, so it can go anywhere a String literal can, including switch labels and annotations. Pitfalls are mostly about hidden whitespace, the trailing newline, and the required newline after the opening delimiter.
A teammate proposes using StringBuffer as a shared field so several worker threads can append log lines to it concurrently. Critique this design.
basics
~20 sStringBuffer keeps each append from corrupting the buffer, but it does not control the order, makes every thread fight over one lock, and you still need extra synchronization to read it safely. A shared mutable builder is a bottleneck and a smell; give each thread its own builder or use a proper concurrent structure.
As an API designer, how do you reason about the trade-offs of String immutability, and when does it become a liability (e.g. sensitive data)?
basics
~20 sImmutability makes Strings safe and easy to share, but it has a downside: you cannot wipe a String from memory after use. For passwords and secrets, prefer char[] (or a byte buffer) that you can overwrite, because immutable Strings linger in memory and the pool.
Why was String's internal representation able to change from char[] to byte[] without breaking applications, and what does that teach about API/implementation boundaries at platform scale?
basics
~20 sThe internal array was private, and the public methods (length, charAt, etc.) kept their exact behavior. So the JVM could swap char[] for byte[] without changing anything visible to programs - well-behaved code never depended on the hidden field.
When is calling intern() a good idea at scale, and what are the risks and alternatives?
basics
~20 sintern() helps when you have many duplicate runtime strings drawn from a small set, because it collapses them to one shared object and saves memory. It hurts when values are mostly unique, because the pool grows, lookups cost time, and GC suffers. Often a plain HashMap cache or JVM string deduplication is safer.
showing 31–38 of 38