String Handling in Java: String Pool, Immutability and Fresher-Test Questions

Strings are a commonly tested Java topic in fresher assessments. Output-based questions on the String pool, == versus equals(), and StringBuilder reward a precise model of references, content and mutation.

The good news is that the whole trap set rests on just two ideas: the String pool and immutability. Understand those two cold, and every output question on this page becomes a twenty-second read.

String pool in Java: where your strings actually live

When you write a string literal, the JVM does not blindly create a new object. It first checks a special region called the String Constant Pool (kept inside the heap in modern JVMs). If an identical string already sits in the pool, the JVM reuses it. If not, it creates one there.

String a = "kg";
String b = "kg";

Here only one object exists. Both a and b point to the same pooled "kg".

The new keyword changes everything:

String c = new String("kg");

new String() always creates a fresh object in the normal heap, outside the pool, even when an identical string already exists in the pool. So after these three lines you have two objects: the pooled "kg" shared by a and b, and a separate heap "kg" owned by c.

One more tool completes the picture: intern(). Calling c.intern() returns the pooled version of that string, adding it to the pool first if needed. Examiners build their trickiest true or false outputs with it.

String immutability in Java: why no method ever changes a string

A Java String is immutable: once created, its characters can never change. Every method that looks like it modifies a string, such as concat(), toUpperCase(), replace(), trim(), actually returns a new String object and leaves the original untouched.

Java made this choice deliberately, and interviewers love asking why:

• Pool sharing is only safe with immutability. If a and b share one pooled object and strings were mutable, changing the string through a would silently corrupt b.

• The hash code is cached. String computes its hash once and reuses it, which is why strings make fast, safe HashMap keys.

• Security and thread safety. File paths, class names and network URLs are passed as strings; immutability guarantees they cannot be altered after validation, and strings can be shared across threads without locks.

The classic trap this produces:

String s = "knowledge";
s.toUpperCase();
System.out.println(s);

Output: knowledge, in lowercase. The uppercase string was created and immediately discarded because nobody stored the returned reference. Any time a string method is called without an assignment, the original string is unchanged. That one observation answers a surprising number of output questions.

== vs equals() in Java strings: the trap, worked step by step

== compares references: do the two variables point to the same object? equals() on String compares content: do the two objects hold the same characters? Mixing these up is the single most common wrong answer in Java fresher tests.

Walk through this example one line at a time:

String a = "kg";
String b = "kg";
String c = new String("kg");
String d = c.intern();

• Line 1: "kg" is created in the pool; a points to it.

• Line 2: the pool already has "kg", so b points to the same object as a.

• Line 3: new forces a fresh heap object; c points to a second "kg" outside the pool.

• Line 4: intern() returns the pooled "kg", so d points to the same object as a and b.

Now every comparison is mechanical:

One compile-time twist completes the topic. "k" + "g" is folded by the compiler into the literal "kg", so it comes from the pool. But if one operand is a variable, the concatenation happens at runtime and produces a new heap object:

String x = "k";
String y = x + "g";
System.out.println(y == "kg");   // false
System.out.println(y.equals("kg")); // true

StringBuilder vs String: the performance question interviewers love

Because String is immutable, this innocent loop is a performance mistake:

String result = "";
for (int i = 0; i < 10000; i++) {
    result = result + i;
}

Every iteration creates a brand-new String and copies all previous characters into it. The copying cost grows with the string length, so the loop does quadratic work overall.

StringBuilder fixes this with a mutable internal character array. append() writes into the existing buffer and only occasionally resizes it, so building the same string becomes linear:

StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) {
    sb.append(i);
}
String result = sb.toString();

The comparison table interviewers expect you to reproduce:

The one-line answer for "StringBuilder vs StringBuffer": same API, but StringBuffer synchronizes every method and is slower, so prefer StringBuilder unless multiple threads share the builder.

String questions in fresher tests: the patterns to expect

Service-company assessments often use output-based Java questions in coding and programming-concepts sections. The exact section split and question mix change from drive to drive, so treat the patterns below as preparation targets and confirm the current format in the company announcement before your test day. For how one such paper is organised, our walkthrough of the TCS NQT exam structure covers the sections one by one.

Try these four in your head before reading the answers. Every one of them is a direct application of the sections above.

Question 1. What does this print?

String a = "kg";
String b = new String("kg");
System.out.println(a == b);
System.out.println(a.equals(b));

Answer: false, then true. Reference comparison fails across pool and heap; content comparison passes.

Question 2. What does this print?

String s = "know";
s.concat("ledge");
System.out.println(s);

Answer: know. The concatenated string was returned and discarded; immutability guarantees s never changed.

Question 3. What does this print?

String a = "kg";
String b = "k" + "g";
String c = "k";
String d = c + "g";
System.out.println(a == b);
System.out.println(a == d);

Answer: true, then false. "k" + "g" is folded at compile time into the pooled "kg", but c + "g" runs at runtime and creates a new heap object.

Question 4. What does this print?

StringBuilder sb = new StringBuilder("java");
sb.append("dev").delete(0, 1);
System.out.println(sb);

Answer: avadev. StringBuilder is mutable, so the chain modifies one object in place: "java" becomes "javadev", then deleting index 0 leaves "avadev".

If any answer surprised you, reread the matching section; each maps to exactly one concept. For the aptitude and reasoning sections alongside Java in these tests, the Placement Preparation category collects our courses and guides in one place.

The short version, and your next step

Four sentences carry this topic. Literals live in the shared String pool; new String() always makes a separate heap object. Strings never change; every modifying method returns a new object. == compares references, equals() compares content, intern() bridges the two. Build strings in loops with StringBuilder, never with +.

To place string handling inside the full language, the Complete Java course takes you from core syntax through OOP, collections and multithreading with working code for every concept. And when you are ready to test yourself under exam conditions, the TCS NQT and Smart Hiring Test Series puts these exact question styles on a timer.

Trace the four output questions above by hand until the pool diagram appears in your head unprompted. From that point on, string questions are the easiest marks on the paper.