Cosmic Module

J

Qubits of DPK

March 14, 2026

Core Java

Layman Explanation

A String is like a printed certificate. Once printed, you cannot change it. If you want a different name, you print a brand new certificate. The old one still exists unchanged.

What is String?

java
QUBITS OF DPK
1String name = "Deepak";   // String literal → String Pool
2String name = new String("Deepak");  // forced heap object
  • String is NOT a primitive — it's a Class (java.lang.String)
  • String literals go to String Pool inside Heap
  • Identical literals share the same pool object (memory efficient)

String Pool

java
QUBITS OF DPK
1String a = "Deepak";
2String b = "Deepak";
3String c = new String("Deepak");
4
5a == b         // true  ← same String Pool object
6a == c         // false ← c is forced new heap object
7a.equals(c)    // true  ← same content
javascript
QUBITS OF DPK
1Heap:
2│
3├── String Pool
4│   └── "Deepak" ◄── a points here
5│              ◄── b points here (same!)
6│
7└── Regular Heap
8    └── "Deepak" ◄── c points here (separate!)

Why String is Immutable

Reason 1 — String Pool Efficiency

If String were mutable — changing one reference would corrupt all others sharing same pool object.

Reason 2 — Thread Safety

Multiple threads can read same String without synchronization.

Reason 3 — Security

Passwords, URLs, DB connections are Strings. Immutability prevents tampering after validation.

Immutability in Action

java
QUBITS OF DPK
1String name = "Deepak";
2name.concat(" Kumar");          // creates new String but NOT assigned!
3System.out.println(name);       // still "Deepak" ⚠️
4
5name = name.concat(" Kumar");   // ✅ reassign
6System.out.println(name);       // "Deepak Kumar"
Memory trace:
javascript
QUBITS OF DPK
1Step 1: name → "Deepak" (in pool)
2Step 2: concat creates "Deepak Kumar" (new object)
3Step 3: name now → "Deepak Kumar"
4        "Deepak" still exists in pool, untouched

Performance Problem with String

java
QUBITS OF DPK
1String result = "";
2for (int i = 0; i < 10000; i++) {
3    result = result + i;   // ❌ creates NEW object every iteration!
4}                          // 10,000 objects created!

Interview Answer (SDE-2)

"String in Java is immutable — once created it cannot be changed. Every modification creates a new String object, while the original stays in the String Pool. This enables memory reuse via String Pool, thread safety without synchronization, and security for sensitive data like passwords. The downside is performance in loops — StringBuilder solves this with a mutable character buffer."

Interview Questions & MAANG-Level Answers

Q1. Why is String immutable in Java?
Three reasons: (1) String Pool efficiency — multiple references can safely share the same String object in pool without one modifying it for others. (2) Thread safety — immutable objects are inherently thread-safe, no synchronization needed when multiple threads read the same String. (3) Security — passwords, DB connection URLs, and class names are Strings. If mutable, an attacker could change a password after validation but before use. Also enables hashCode caching since value never changes.
Q2. What is the String Pool?
String Pool (also called String Intern Pool) is a special memory area inside Heap where String literals are cached. When you write String a = "hello", Java checks if "hello" already exists in pool — if yes, reuses it; if no, creates it. So String a = "hello"; String b = "hello"; — both point to same pool object. new String("hello") bypasses pool. String.intern() explicitly adds a string to pool and returns the pool reference.
Q3. What is the difference between == and .equals() for Strings?
== compares memory addresses (references). String a = "hi"; String b = "hi"; a == b is true (same pool object). But String c = new String("hi"); a == c is false (different heap objects with same content). .equals() compares actual character content — always use .equals() for String comparison in production code. Rule: never use == for String comparison.
Q4. Why is String concatenation in a loop inefficient?
Strings are immutable. result = result + i creates a NEW String object every iteration — the old one is abandoned for GC. For 10,000 iterations: 10,000 objects created, 9,999 immediately abandoned. GC pressure + O(n²) total character copying. Fix: use StringBuilder.append() which modifies the same internal char array. Benchmark: String loop ~350ms vs StringBuilder ~2ms for 10,000 iterations.
Q5. What is the output of s.concat(" Kumar") without reassigning?
java
QUBITS OF DPK
1String name = "Deepak";
2name.concat(" Kumar");  // creates new String but discarded!
3System.out.println(name);  // "Deepak"
Output: "Deepak". concat() creates a new String object with the combined value, but since it's not assigned back, the new object is immediately eligible for GC. The original name still points to "Deepak" in String Pool. This is the most common String immutability trap.