Java — Concept Notes

1. What Java Is: JDK, JRE & JVM

JDK vs JRE vs JVM

Bytecode and "write once, run anywhere"

C or C++ compile straight to machine code for one CPU and OS; to run on another platform you recompile. Java adds a middle step: javac produces bytecode, a compact, platform-neutral instruction set stored in .class files. Each platform has its own JVM that understands that same bytecode. So the same .class or .jar file runs on Windows, macOS and Linux without recompiling — "write once, run anywhere" (WORA).

• Bytecode is platform independent; the JVM is not. This is the most common trick question in this area.
• Bytecode is not only for Java. Kotlin, Scala, Groovy and Clojure also compile to .class files, so they run on the same JVM and can call Java libraries.
• WORA has limits: native code (JNI), OS-specific file paths (\ vs /) and line endings can still make a program behave differently. Use Path.of(...) and System.lineSeparator().

Is Java compiled or interpreted?

Both. Source is compiled ahead of time to bytecode by javac. At run time the JVM first interprets bytecode (reads and executes it instruction by instruction), and the JIT (Just-In-Time) compiler turns frequently-run "hot" methods into optimised native machine code. That is why long-running Java servers get faster after a warm-up period. Section 2 walks through this pipeline in detail.

What kind of language is Java?

Versions you should know

Since Java 10 (2018) a new version ships every six months. Every few releases is an LTS (Long-Term Support) version that companies actually run in production.

Distributions and JVM implementations

• OpenJDK is the open-source reference code. Oracle JDK, Eclipse Temurin, Amazon Corretto, Azul Zulu and Microsoft Build of OpenJDK are all builds of it — functionally almost identical; they differ in licence and support.
• HotSpot is the standard JVM inside those builds. Alternatives: OpenJ9 (low memory footprint) and GraalVM, whose native image compiles an app ahead of time into a standalone binary that starts in milliseconds (no JIT warm-up, but less peak optimisation).

// Check what you are running on
public class S1Runtime {
    public static void main(String[] args) {
        System.out.println(Runtime.version().feature());          // 21
        System.out.println(System.getProperty("java.vm.name"));   // Java HotSpot(TM) 64-Bit Server VM
    }
}
// From a terminal:  java -version   and   javac -version

The JVM is a specification

"The JVM" means two things. The JVM Specification is a document that defines the bytecode instruction set, the .class file format, how classes are loaded and linked, and what memory areas must exist. A JVM implementation (HotSpot, OpenJ9, GraalVM) is a real program that follows that document. The spec says what must happen — for example "unreachable objects may be reclaimed" — but not how, so garbage collectors and JIT compilers differ between implementations and even between versions of HotSpot.

The Java Language Specification (JLS) is a separate document that defines the language itself (syntax, types, overload rules). javac follows the JLS; the JVM follows the JVM spec. Other JVM languages skip the JLS entirely and only target the JVM spec.

Common misconceptions

Trying things quickly: jshell (Java 9)

$ jshell
jshell> int x = 7 / 2;
x ==> 3
jshell> "java".toUpperCase()
$2 ==> "JAVA"
jshell> List.of(3, 1, 2).stream().sorted().toList()
$3 ==> [1, 2, 3]
jshell> /exit

jshell is a REPL (read-eval-print loop) shipped with the JDK: no class, no main, no semicolon needed for expressions, and common packages like java.util are imported for you. Ideal for checking an edge case during interview prep.

2. How a Java Program Runs

Step 1 — compile with javac

public class Hello {
    static int add(int a, int b) {
        return a + b;
    }
    public static void main(String[] args) {
        System.out.println("Hello, " + (args.length > 0 ? args[0] : "world"));
        System.out.println(add(2, 3));
    }
}

// $ javac Hello.java        -> creates Hello.class
// $ java Hello              -> Hello, world   then 5
// $ java Hello Ana          -> Hello, Ana     then 5

• javac takes a file name (Hello.java); java takes a class name (Hello). java Hello.class fails with "Could not find or load main class Hello.class".
• A public class must live in a file with the same name. Each class — including nested ones — becomes its own file: App.java with a nested Helper produces App.class and App$Helper.class.
• The compiler checks types, resolves overloads, folds constants, and reports errors — but does little optimisation. The heavy optimisation happens later in the JIT.

You can look at bytecode with javap -c. The JVM is a stack machine: instructions push values onto an operand stack and pop them off.

$ javap -c Hello
  static int add(int, int);
    Code:
       0: iload_0        // push local variable 0 (a)
       1: iload_1        // push local variable 1 (b)
       2: iadd           // pop both, push a + b
       3: ireturn        // return the int on top of the stack
  ...
      16: invokedynamic #15,  0   // InvokeDynamic #0:makeConcatWithConstants  (string +, Java 9+)
      29: invokestatic  #25       // Method add:(II)I

Packages, classpath and JARs

// src/com/acme/App.java  starts with:  package com.acme;
$ javac -d out src/com/acme/App.java      // -d puts classes in out/com/acme/
$ java -cp out com.acme.App               // -cp = classpath; use the FULLY qualified name
App running from package com.acme

$ jar --create --file app.jar --main-class com.acme.App -C out .
$ java -jar app.jar                        // manifest says which class has main
App running from package com.acme

The classpath is the list of folders and JARs where the class loader looks for classes. Using the simple name (java -cp out App) fails with ClassNotFoundException: App.

Step 2 — class loading (loading, linking, initialisation)

1. Loading — a class loader reads the bytes of the .class file and creates a Class object in memory (class metadata goes into Metaspace, which replaced PermGen in Java 8).
2. Linking — verify (bytecode is well-formed and type-safe: no stack overflow tricks, no jumping into the middle of an instruction); prepare (allocate static fields with default values); resolve (turn symbolic names like java/lang/System into real references, often lazily).
3. Initialisation — run static initialisers and assign static field values. This happens on first active use of the class, not at start-up.

Loaders use parent delegation: before loading a class itself, a loader asks its parent first. So a class named java.lang.String on your classpath can never replace the real one — the bootstrap loader always wins. This is a security feature.

public class S2Loaders {
    static { System.out.println("S2Loaders initialised"); }
    static class Lazy {
        static { System.out.println("Lazy initialised"); }
        static int X = 1;
    }
    public static void main(String[] args) {
        System.out.println(String.class.getClassLoader());                          // null
        System.out.println(java.sql.Connection.class.getClassLoader().getName());   // platform
        System.out.println(S2Loaders.class.getClassLoader().getName());             // app
        System.out.println("before Lazy");
        System.out.println(Lazy.X);   // first use: prints "Lazy initialised", then 1
    }
}
// Output order: S2Loaders initialised, null, platform, app, before Lazy, Lazy initialised, 1

Step 3 — execution: interpreter plus JIT

The interpreter starts instantly but is slow per instruction. The JVM counts how often each method is called and each loop runs. When a method becomes hot, HotSpot compiles it to native code using tiered compilation:

$ java -XX:+PrintCompilation JitDemo | grep JitDemo::
     53    7       2       JitDemo::square (4 bytes)
     53    8       4       JitDemo::square (4 bytes)          // promoted to C2
     53    7       2       JitDemo::square (4 bytes)   made not entrant   // old version retired
     57    9 %     3       JitDemo::main @ 4 (32 bytes)       // % = on-stack replacement of a hot loop
// Timings and ids differ on every run.

Because the JIT uses real run-time data (which branches are taken, which class a call site actually sees), it can sometimes beat ahead-of-time compiled code at peak speed. The price is warm-up: the first requests to a fresh JVM are slower. OSR (on-stack replacement) lets a long loop already running in main switch to compiled code mid-loop.

JVM run-time memory areas (overview)

The main method

public static void main(String[] args)

• public — the launcher calls it from outside the class. static — it runs before any object exists. void — the exit code is set with System.exit(n), not returned. String[] args — command-line arguments (never null; empty array if none).
• Also legal: String... args, final String[] args, static public. You may overload main, but the launcher only calls the String[] version.
• Wrong signature (say static void main()) compiles fine but fails at launch: "Error: Main method not found in class NoMain, please define the main method as: public static void main(String[] args)".

Single-file launch and simpler main

// Java 11 (JEP 330): run a source file directly -- compiled in memory, no .class written
$ java Hello.java Bob
Hello, Bob
5

// Java 21 PREVIEW (JEP 445): unnamed class + instance main.  File Simple.java:
void main() {
    System.out.println("No class, no static, no String[] args");
}
$ java --enable-preview --source 21 Simple.java
No class, no static, no String[] args

In Java 21 the simpler main needs --enable-preview; it was finalised in Java 25 as "compact source files and instance main methods". Java 22 extended source launch to programs with several files. For quick experiments, use jshell (section 1).

Errors you will meet at this stage

3. Types, Variables & Wrappers

The 8 primitive types

• Sizes are fixed on every platform — an int is always 32 bits, unlike C. All integer types are signed except char.
• Defaults apply only to fields and array elements. A local variable has no default: reading it before assigning is a compile error — variable x might not have been initialized.
• An integer literal is an int by default: long big = 3_000_000_000; fails with "integer number too large" — add L. A decimal literal is a double: float f = 3.14; fails with "possible lossy conversion from double to float" — add f.
• char is a number: 'A' + 1 is 66, and (char) ('A' + 1) is 'B'.

Primitive vs reference

Wrappers, autoboxing and unboxing (Java 5)

Wrappers exist because generics and collections only hold objects, because sometimes you need "no value" (null), and to host helper methods like Integer.parseInt, Integer.MAX_VALUE, Character.isDigit. Wrappers are immutable. The compiler inserts the conversion calls for you:

Integer boxed = 42;          // compiler writes: Integer.valueOf(42)      (autoboxing)
int back = boxed;            // compiler writes: boxed.intValue()         (unboxing)
List<Integer> list = new ArrayList<>();
list.add(7);                 // boxes 7
int first = list.get(0);     // unboxes

Integer.parseInt("123") + 1; // 124  String -> int
Integer.toBinaryString(10);  // "1010"
// new Integer(5) is deprecated (Java 9) and marked for removal (Java 16): use Integer.valueOf(5)

The Integer cache (-128 to 127)

Integer.valueOf — and therefore autoboxing — returns a cached, shared object for values from -128 to 127. Outside that range it creates a new object each time. So == on two Integers "works" for small numbers and silently breaks for larger ones.

Integer a = 127, b = 127, x = 128, y = 128;
System.out.println(a == b);          // true   same cached object
System.out.println(x == y);          // false  two objects
System.out.println(x.equals(y));     // true   compare values with equals

Long l1 = 127L, l2 = 127L;
System.out.println(l1 == l2);        // true   Long, Short, Byte also cache -128..127
Integer mixed = 1000; int prim = 1000;
System.out.println(mixed == prim);   // true   one side is primitive, so the other is UNBOXED
System.out.println(Long.valueOf(1).equals(1));  // false  1 boxes to Integer, not Long

Map<String, Integer> m = new HashMap<>();
int v = m.get("missing");            // NullPointerException: unboxing null

• Character caches 0–127, Boolean has just TRUE/FALSE. Float/Double have no cache. The Integer upper bound can be raised with -XX:AutoBoxCacheMax=<n> — never rely on it.
• Rule: compare wrappers with equals (or unbox first). Beware a null wrapper being unboxed in arithmetic, if (flag), or a ternary.
• Boxing in a hot loop (Long sum = 0L; sum += i;) creates millions of objects. Use primitives for arithmetic.

Widening and narrowing conversions

int i = 100;  long wl = i;  double wd = wl;     // 100  100.0   widening, always safe in range
(int) 3.99            // 3            cast TRUNCATES toward zero (no rounding)
(int) -3.99           // -3
Math.round(3.99)      // 4            use Math.round / floor / ceil to round
(byte) 300            // 44           keeps the low 8 bits: 300 - 256
(int) 1e20            // 2147483647   double->int clamps to MAX_VALUE
(long) Double.NaN     // 0

// Widening can still LOSE PRECISION: long -> float and int -> float
long precise = 123456789123456789L;
float lossy = precise;          // compiles without a cast!
(long) lossy                    // 123456790519087104   digits lost
float ff = 16_777_217;          // 2^24 + 1
(int) ff                        // 16777216

// Arithmetic on byte/short/char is done in int
byte p = 10, q = 20;
int r = p + q;                  // OK
// byte r2 = p + q;             // compile error: possible lossy conversion from int to byte
byte r2 = (byte) (p + q);       // 30

Overflow — silent wrap-around

int max = Integer.MAX_VALUE;
max + 1                                // -2147483648  wraps to MIN_VALUE, no exception
Math.abs(Integer.MIN_VALUE)            // -2147483648  still negative!
long wrong = 1_000_000 * 1_000_000;    // -727379968   int*int overflowed BEFORE widening
long right = 1_000_000L * 1_000_000;   // 1000000000000
Math.multiplyExact(1_000_000, 1_000_000);  // throws ArithmeticException: integer overflow
// also addExact, subtractExact, toIntExact; BigInteger for arbitrary size

Floating point is approximate

0.1 + 0.2                  // 0.30000000000000004  (binary cannot store 0.1 exactly)
0.1 + 0.2 == 0.3           // false -- compare with Math.abs(a - b) < 1e-9
new BigDecimal("0.1").add(new BigDecimal("0.2"))   // 0.3  use BigDecimal (from String!) for money
1.0 / 0                    // Infinity   (no exception for doubles)
0.0 / 0                    // NaN
Double.NaN == Double.NaN   // false -- use Double.isNaN(x)
7 / 0                      // ArithmeticException: / by zero   (integers DO throw)

var — local type inference (Java 10)

var names = new ArrayList<String>();   // type is ArrayList<String>, fixed at compile time
var count = 0;                          // int
// var x;            // error: cannot infer without an initialiser
// var n = null;     // error
// Only for local variables (and for-loop / lambda params) -- not fields, not method params or returns.

var is not dynamic typing: the compiler infers one fixed type. Use it when the right-hand side makes the type obvious; avoid it when it hides the type (var result = service.process();).

4. Operators & Control Flow

Arithmetic: integer division and remainder

7 / 2              // 3     int / int = int; the fraction is dropped (truncated toward zero)
-7 / 2             // -3    toward zero, not -4
7 / 2.0            // 3.5   one double operand makes the whole division double
double avg = 7 / 2;  // 3.0 -- the division happened in int BEFORE assignment
7 % 3              // 1
-7 % 3             // -1    result takes the sign of the LEFT operand
Math.floorMod(-7, 3) // 2   always non-negative for a positive divisor (use for wrap-around indexes)
7 / 0              // ArithmeticException: / by zero
7.0 / 0            // Infinity

Fix the "average" bug by making one operand a double first: (double) sum / count. Writing (double) (sum / count) is too late — the truncation already happened.

Increment: pre vs post

Java guarantees left-to-right evaluation of operands, so these results are defined (unlike in C). Still, never write this in real code — use i++ alone on its own line or in a for header.

Compound assignment hides a cast

short sh = 10;
sh += 5;          // OK: means sh = (short) (sh + 5)
// sh = sh + 5;   // compile error: possible lossy conversion from int to short
byte by = 127;
by += 1;          // -128 -- the hidden cast lets it overflow silently

Logical operators and short-circuiting

&& and || short-circuit: if the left side already decides the answer, the right side is not evaluated. & and | on booleans always evaluate both sides.

static boolean check(String label, boolean result) {
    System.out.println("  evaluated " + label);
    return result;
}
boolean r1 = check("left", false) && check("right", true);   // prints only: evaluated left
boolean r2 = check("left", false) &  check("right", true);   // prints: evaluated left, evaluated right

String s = null;
if (s != null && s.length() > 3) { ... }   // safe: length() never runs when s is null

Bitwise and shift operators

6 & 3     // 2    AND   110 & 011 = 010
6 | 3     // 7    OR    110 | 011 = 111
6 ^ 3     // 5    XOR   110 ^ 011 = 101
~6        // -7   NOT   flips every bit (two's complement: ~x == -x - 1)
1 << 4    // 16   shift left  = multiply by 2^4
-16 >> 2  // -4   arithmetic right shift keeps the sign bit
-16 >>> 28 // 15  logical right shift fills with zeros

Precedence you actually need

String + is evaluated left to right too: 1 + 2 + "3" + 4 + 5 is "3345" — numbers add until the first String appears, then everything is concatenation. When in doubt, add brackets.

The ternary operator

String grade = score >= 90 ? "A" : score >= 70 ? "B" : "C";   // score 72 -> "B"

// Trap 1: unboxing null
Integer nullable = null;
int v = true ? nullable : 0;       // NullPointerException -- the result type is int, so nullable is unboxed
// Trap 2: numeric promotion
System.out.println(true ? 1 : 2.0);   // 1.0 -- both branches promoted to double

switch statement (classic) — watch the fall-through

int day = 2; String name;
switch (day) {
    case 1: name = "Mon";
    case 2: name = "Tue";          // no break: falls through to the next case!
    case 3: name = "Wed"; break;
    default: name = "?";
}
System.out.println(name);          // Wed

Classic switch works on byte, short, char, int (and their wrappers), String (Java 7, compared with equals) and enum. It cannot switch on long, float, double or boolean.

switch expression (Java 14)

String dayName = switch (day) {
    case 1, 7 -> "Weekend-ish";      // several labels, comma-separated
    case 2 -> "Tue";                 // arrow: no fall-through, no break needed
    default -> {
        String tmp = "Day " + day;
        yield tmp;                   // yield returns a value from a block
    }
};                                   // it is an expression, so it ends with ;

Pattern matching (Java 16 – 21)

instanceof patterns (Java 16) test and cast in one step; the new variable is only in scope where the test is true:

Object o = "hello";
if (o instanceof String str && str.length() > 3) {
    System.out.println(str.toUpperCase());      // HELLO -- no manual (String) cast
}

Pattern matching for switch (preview in 17–20, final in Java 21) lets you switch on type, add when guards, handle case null, and destructure records with record patterns (also final in Java 21). With a sealed hierarchy the compiler knows every subtype, so no default is needed.

sealed interface Shape permits Circle, Square, Rect {}
record Circle(double r) implements Shape {}
record Square(double side) implements Shape {}
record Rect(double w, double h) implements Shape {}

static double area(Shape s) {
    return switch (s) {                           // exhaustive: all 3 permitted types covered
        case Circle c -> Math.PI * c.r() * c.r();
        case Square sq -> sq.side() * sq.side();
        case Rect(double w, double h) -> w * h;   // record pattern: pulls out the components
    };
}

static String describe(Object o) {
    return switch (o) {
        case null -> "null!";                      // without this, a null throws NPE
        case Integer i when i > 100 -> "big int " + i;   // guard; more specific case first
        case Integer i -> "int " + i;
        case String str -> "string of length " + str.length();
        default -> "something else";
    };
}
// area: 3.14, 4.00, 6.00     describe(500) = "big int 500", describe(2.5) = "something else"

Unnamed patterns _ were a preview in Java 21 (final in Java 22): if (o instanceof Point(int x, _)) ignores components you do not need. In Java 21 they need --enable-preview --source 21. Pattern matching on primitive types is a later preview (Java 23+).

Loops, break and continue

for (int i = 0; i < n; i++) { ... }       // classic
for (var x : new int[]{1, 2, 3}) { ... } // enhanced for: arrays and any Iterable; no index
while (cond) { ... }                      // may run 0 times
do { n++; } while (n < 0);               // runs at least once -- n becomes 1

outer:                                    // label: break out of BOTH loops at once
for (int r = 0; r < 3; r++) {
    for (int c = 0; c < 3; c++) {
        if (r * c == 2) { System.out.println("found at " + r + "," + c); break outer; }
    }
}
// found at 1,2     (continue outer; would skip to the next r instead)

• Modifying a List while looping over it with enhanced for throws ConcurrentModificationException — use an Iterator and it.remove(), or removeIf.
• Comparing floats: 0.1f == 0.1 is false (the float is widened to a slightly different double).

5. Strings

Immutability in practice

String s = "java";
s.toUpperCase();          // creates "JAVA" and throws it away
System.out.println(s);    // java
s = s.toUpperCase();      // re-point s at the new object
System.out.println(s);    // JAVA

The variable s can be re-pointed; the object "java" never changes. String is a final class (no subclass can add mutability), its internal array is private, and no method modifies it.

Why immutable?

• Pooling — sharing one copy is only safe if nobody can change it.
• Security — file paths, URLs, class names and passwords checked once cannot be altered afterwards by another reference.
• Thread safety — can be shared across threads with no locking.
• Hash caching — hashCode() is computed once and cached, which makes strings fast HashMap keys.

Inside, since Java 9 (compact strings) a String stores a byte[] plus a "coder" flag: 1 byte per character when all characters are Latin-1, 2 bytes (UTF-16) otherwise. That roughly halves memory for typical English text.

The String pool, == and equals

String a = "hello";
String b = "hello";
String c = new String("hello");
String d = c.intern();
a == b          // true   same pooled object
a == c          // false  c is a separate heap object
a.equals(c)     // true   same characters
a == d          // true   intern() returns the pooled copy

// Compile-time constants are folded into one literal; runtime concatenation is not
String hel = "hel";
final String helFinal = "hel";
a == "hel" + "lo"          // true   folded to "hello" by javac
a == hel + "lo"            // false  built at run time -> new object
a == helFinal + "lo"       // true   final + literal is a constant expression
a == (hel + "lo").intern() // true

• Always compare content with equals. == compares references and only "works" by accident with literals.
• Null-safe comparison: "x".equals(maybeNull) (literal first) or Objects.equals(a, b). equalsIgnoreCase ignores case; compareTo orders alphabetically (by UTF-16 code).
• Since Java 7 the pool lives in the normal heap (it was in PermGen before), so pooled strings can be garbage collected.
• intern() can reduce memory when you have millions of duplicate strings, but it costs a hash lookup; modern GCs (G1) can also do string deduplication automatically (-XX:+UseStringDeduplication).
• new String("hello") may create two objects — the pooled literal (if not already there) and the new heap copy. A classic trivia question.

String vs StringBuilder vs StringBuffer

// Bad: O(n^2) -- each += copies everything built so far
String acc = "";
for (int i = 0; i < 20_000; i++) acc += "x";

// Good: amortised O(1) append
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 20_000; i++) sb.append("x");
String result = sb.toString();

StringBuilder b2 = new StringBuilder("ab");
b2.append('c').append(1).insert(0, "[").append("]");   // [abc1]  (methods chain)
b2.length();                                            // 6
b2.reverse();                                           // ]1cba[  (in place)
// also: deleteCharAt, setCharAt, setLength, replace, indexOf

A single-line "a" + x + "b" is fine: since Java 9 the compiler emits one invokedynamic call (StringConcatFactory) that sizes the result once. The problem is only += inside a loop. Note that StringBuilder does not override equals — compare with sb1.toString().equals(...) or sb1.compareTo(sb2) (Java 11).

Text blocks (Java 15)

String json = """
    {
      "name": "Ana",
      "age": 30
    }
    """;          // indentation up to the closing """ is stripped; ends with a newline
String oneLine = """
    one \
    line""";      // backslash joins lines; closing """ on the same line = no trailing newline
// oneLine is "one line"

Text blocks are ordinary Strings (same pool, same methods) — just easier to write multi-line JSON, SQL and HTML without \n and escaped quotes.

Common methods

Pitfalls

• split takes a regex: "a.b.c".split(".") returns an empty array because . matches every character. Use split("\\.") → [a, b, c].
• substring, replace, trim return new strings — forgetting to assign the result is a silent bug.
• Different strings can share a hash: "Aa".hashCode() and "BB".hashCode() are both 2112. Equal hash never means equal strings.
• length() counts UTF-16 code units, not visible characters — an emoji or some CJK characters take 2. Use codePointCount when that matters.
• Do not keep passwords in a String (it lingers in memory until GC and may be pooled) — APIs use char[] so you can wipe it.

6. Arrays

Declaring and creating

int[] nums = new int[3];          // [0, 0, 0]           size fixed at 3
int[] primes = {2, 3, 5, 7};      // initializer (only in a declaration)
int[] more = new int[]{1, 2};     // anonymous array: usable anywhere, e.g. as an argument
int legacy[] = new int[2];        // C-style; legal but avoid -- keep [] with the type
String[] strs = new String[2];    // [null, null]  -- no String objects created yet!

primes.length                     // 4    a FIELD (no parentheses); String uses length()
primes[4]                         // ArrayIndexOutOfBoundsException: Index 4 out of bounds for length 4
new int[0]                        // legal empty array; return this instead of null
System.out.println(primes);       // [I@5ca881b5  -- type code + hash, NOT the contents
Arrays.toString(primes)           // [2, 3, 5, 7]

Arrays are checked on every access: an invalid index always throws, it never reads random memory as in C. The size can be a run-time value (new int[n]) but is limited to about Integer.MAX_VALUE because indexes are int.

2D and jagged arrays

int[][] grid = new int[2][3];          // 2 rows x 3 columns, all 0
grid[1][2] = 9;
Arrays.deepToString(grid)              // [[0, 0, 0], [0, 0, 9]]

int[][] jagged = new int[3][];         // only the outer array; rows are null for now
jagged[0] = new int[]{1};
jagged[1] = new int[]{1, 2};
jagged[2] = new int[]{1, 2, 3};
Arrays.deepToString(jagged)            // [[1], [1, 2], [1, 2, 3]]
jagged[2].length                       // 3 -- each row has its own length

for (int[] row : jagged) {             // always use row.length, never assume a rectangle
    for (int v : row) { ... }
}

Because rows are separate objects, iterating row by row (grid[r][c] with c in the inner loop) is cache-friendly; iterating column-first jumps between objects and is noticeably slower on large grids.

The Arrays utility class

int[] data = {5, 2, 9, 1};
Arrays.sort(data);                        // [1, 2, 5, 9]   dual-pivot quicksort for primitives
Arrays.binarySearch(data, 5)              // 2              array MUST be sorted
Arrays.binarySearch(data, 3)              // -3             not found: -(insertionPoint) - 1
Arrays.copyOf(data, 6)                    // [1, 2, 5, 9, 0, 0]   pads with defaults (or truncates)
Arrays.copyOfRange(data, 1, 3)            // [2, 5]         end exclusive
Arrays.fill(filled, 7)                    // [7, 7, 7, 7]
Arrays.setAll(sq, i -> i * i)             // [0, 1, 4, 9, 16]
Arrays.stream(data).sum()                 // 17
Arrays.compare(new int[]{1, 2}, new int[]{1, 3})          // -1  lexicographic (Java 9)
Arrays.mismatch(new int[]{1, 2, 3}, new int[]{1, 9, 3})   // 1   first differing index (Java 9)

Integer[] boxed = {3, 1, 2};
Arrays.sort(boxed, Comparator.reverseOrder());   // [3, 2, 1]  comparator needs OBJECTS, not int[]

List<Integer> view = Arrays.asList(boxed);       // fixed-size LIST VIEW backed by the array
boxed[0] = 100;  // view is now [100, 2, 1]   -- writes show through both ways
view.add(4);     // UnsupportedOperationException
Arrays.asList(new int[]{1, 2}).size()            // 1 -- a List<int[]> holding one array!

Comparing and copying

int[] x = {1, 2}, y = {1, 2};
x == y                  // false  different objects
x.equals(y)             // false  arrays do NOT override equals (inherits identity from Object)
Arrays.equals(x, y)     // true   compares elements
int[][] g1 = {{1}}, g2 = {{1}};
Arrays.equals(g1, g2)       // false  compares the row REFERENCES
Arrays.deepEquals(g1, g2)   // true   recurses into rows

int[] orig = {1, 2, 3};
int[] alias = orig;  alias[0] = 99;     // same object: orig is now [99, 2, 3]
int[] cloned = orig.clone(); cloned[1] = 42;   // new array: orig unchanged, cloned is [99, 42, 3]

int[][] deep = {{1, 2}, {3, 4}};
int[][] shallow = deep.clone();         // copies the outer array only -- rows are SHARED
shallow[0][0] = 100;                    // deep[0][0] is now 100 too!

int[] dst = new int[5];
System.arraycopy(orig, 0, dst, 1, 3);   // [0, 99, 2, 3, 0]   (src, srcPos, dest, destPos, length)

For a true deep copy of a 2D array, clone each row: int[][] copy = Arrays.stream(deep).map(int[]::clone).toArray(int[][]::new);

Array covariance and ArrayStoreException

Arrays are covariant: because String is a subtype of Object, String[] is treated as a subtype of Object[]. That compiles, but it opens a hole that the JVM must plug at run time — every store into a reference array is type-checked.

Object[] objs = new String[2];   // compiles: covariance
objs[0] = "fine";
objs[1] = 42;                    // compiles, but at run time: ArrayStoreException: java.lang.Integer

// Generics are INVARIANT, so the same mistake is caught at compile time:
// List<Object> lo = new ArrayList<String>();   // compile error

This is one reason you cannot create a generic array (new T[10] or new List<String>[10] are compile errors): generics are erased at run time, so the JVM could not do this store check. Prefer List<T> over T[] in APIs.

Array vs ArrayList

Pitfalls

• Arrays as HashMap/HashSet keys use identity: set.contains(new int[]{1}) is false even after adding new int[]{1}. Use List.of(...) or a record as the key.
• new String[3] gives three nulls — calling a method on an element throws NullPointerException.
• Off-by-one: the last index is length - 1; loop with i < arr.length.
• Returning an internal array exposes it to modification. Return arr.clone() or an unmodifiable list.

7. Methods & Pass-by-Value

Anatomy of a method

//  modifiers     return type  name   parameters              exceptions
    public static int          max   (int first, int... rest) throws IllegalStateException {
        int m = first;
        for (int r : rest) m = Math.max(m, r);
        return m;                // max(3) = 3, max(3, 9, 4) = 9
    }

• The signature is the name plus the parameter types in order: max(int, int[]). Return type, parameter names, modifiers and throws are not part of it.
• static methods belong to the class (Math.max); instance methods need an object and can use this.
• A method returns at most one value. To return several, return a record (Java 16): record MinMax(int min, int max) {}.

Overloading rules

Overloaded methods must differ in the number, types or order of parameters. A different return type alone is not enough:

static int  m(int x) { return 1; }
static long m(int x) { return 2; }   // compile error: method m(int) is already defined

The compiler picks the overload at compile time using the declared (static) types of the arguments, in three phases. It stops at the first phase that finds a match, and within a phase chooses the most specific method:

static String f(int x)     { return "int"; }
static String f(long x)    { return "long"; }
static String f(Integer x) { return "Integer"; }
static String f(Object x)  { return "Object"; }
static String f(int... x)  { return "varargs"; }

f(1)                   // int       exact
f(1L)                  // long      exact
f((byte) 1)            // int       widening byte -> int (closest)
f('a')                 // int       char widens to int
f(Integer.valueOf(1))  // Integer   exact
f("s")                 // Object    String widens to Object
f()  /  f(1, 2)        // varargs   only varargs accepts 0 or 2 args

static String g(long x)    { return "long"; }
static String g(Integer x) { return "Integer"; }
g(5)                   // long      phase 1 (widening) wins before boxing is even tried

static String h(Object o)  { return "Object"; }
static String h(String s)  { return "String"; }
h(null)                // String    both match; String is more specific

static void m(Integer x) {}
static void m(String x) {}
m(null);               // compile error: reference to m is ambiguous

Varargs (Java 5)

static String v(int... x) { return "varargs " + x.length; }
v()                  // varargs 0   -- x is an empty array, never null
v(1, 2, 3)           // varargs 3
v(new int[]{7})      // varargs 1   -- you can pass an array directly

String.format("%s-%s", "a", "b");   // format(String, Object...) -- the classic varargs API

• A varargs parameter is just an array: int... x is int[] x inside the method.
• Only one per method and it must be last. To require at least one value, use (int first, int... rest).
• Each call allocates a new array — avoid in very hot paths (that is why List.of has fixed-arity overloads up to 10 elements).
• Generic varargs (List<String>...) trigger "possible heap pollution" warnings; @SafeVarargs suppresses them when the method only reads the array.

Java is ALWAYS pass-by-value

static class Dog { String name; Dog(String name) { this.name = name; } }

static void bump(int n)      { n = n + 1; }                 // changes the local copy only
static void rename(Dog d)    { d.name = "Max"; }            // follows the copied reference: mutates the object
static void replace(Dog d)   { d = new Dog("Rex"); d.name = "Buddy"; }  // re-points the LOCAL copy only
static void swap(Dog a, Dog b) { Dog t = a; a = b; b = t; }

int n = 5;           bump(n);       // n is still 5
Dog dog = new Dog("Rex");
rename(dog);                        // dog.name is "Max"
replace(dog);                       // dog.name is STILL "Max"
Dog a = new Dog("A"), b = new Dog("B");
swap(a, b);                         // a.name = "A", b.name = "B" -- nothing swapped

More cases that follow from the same single rule:

static void addItem(List<String> list) {
    list.add("new");              // mutates the caller's list  -- visible
    list = new ArrayList<>();     // re-points the local copy   -- invisible
    list.add("lost");
}
List<String> items = new ArrayList<>(List.of("x"));
addItem(items);                   // items is [x, new]

static void mutate(int[] a) { a[0] = 100; a = new int[]{-1, -1}; }
int[] arr = {1, 2};  mutate(arr); // arr is [100, 2]

static void upper(String s)  { s = s.toUpperCase(); }
String s = "hi";     upper(s);    // still "hi"  -- String is immutable, so it can only be re-pointed

static void incBox(Integer i) { i++; }   // i++ means i = Integer.valueOf(i + 1): a NEW object
Integer boxed = 10;  incBox(boxed);      // still 10

To give a result back, return it (s = upper(s)) rather than trying to modify a parameter. That is also cleaner design.

The call stack and recursion

Each call pushes a stack frame holding its parameters and local variables; return pops it. Recursion works because each call gets its own frame — factorial(5) builds 5 frames and returns 120. Recursion with no base case (or too deep) fills the thread's stack and throws StackOverflowError (an Error, not an Exception) — typically after thousands to tens of thousands of frames; the default stack size can be raised with -Xss. Java does not do tail-call optimisation, so deep recursion (say 10⁵ levels) should be rewritten as a loop.

static int factorial(int n) { return n <= 1 ? 1 : n * factorial(n - 1); }   // factorial(5) = 120
static void recurse() { recurse(); }   // StackOverflowError

8. Classes & Objects

Anatomy of a class

public class Pizza {
    // fields (state) -- every object gets its own copy
    private final String size;
    private int toppings;

    // static field -- ONE copy shared by the whole class
    private static int made = 0;

    // constructor -- same name as the class, NO return type
    public Pizza(String size) {
        this.size = size;       // 'this' = the object being built
        made++;
    }

    // instance method -- works on one object's state
    public void addTopping() { toppings++; }

    // static method -- belongs to the class, no 'this'
    public static int totalMade() { return made; }
}

Pizza p = new Pizza("large");   // declare a reference, create the object, link them

What new actually does

Default values: fields yes, local variables no

Constructors

• A constructor has the class's name and no return type. Writing public void Pizza() creates an ordinary method that happens to share the name — a classic trick question.
• If you write no constructor, the compiler adds a public no-arg default constructor. The moment you write any constructor, that free one disappears — so new Pizza() stops compiling after you add Pizza(String).
• Constructors are not inherited and cannot be static, final or abstract. They can be private (singletons, factory methods, utility classes).

Constructor chaining with this(...) and super(...)

this(...) calls another constructor of the same class; super(...) calls a constructor of the parent. Chaining keeps all the real set-up in one place instead of copy-pasting it into every overload.

class Pizza {
    private final String size, crust;
    private final int toppings;

    Pizza()                          { this("medium"); }              // -> next one
    Pizza(String size)               { this(size, "thin"); }
    Pizza(String size, String crust) { this(size, crust, 0); }
    Pizza(String size, String crust, int toppings) {                  // the one "real" constructor
        this.size = size; this.crust = crust; this.toppings = toppings;
    }
    @Override public String toString() { return size + "/" + crust + "/" + toppings; }
}

class Animal {
    final String name;
    Animal(String name) { this.name = name; }
}
class Dog extends Animal {
    Dog() { super("Rex"); }   // REQUIRED: Animal has no no-arg constructor
}

new Pizza();          // medium/thin/0
new Pizza("large");   // large/thin/0
new Dog().name;       // Rex

• this(...) or super(...) must be the first statement, and you can have only one of them. (Java 25 relaxes this a little with "flexible constructor bodies", but in Java 21 it is a hard rule.)
• If you write neither, the compiler inserts super() — which fails to compile if the parent has no no-arg constructor. That is the error "constructor Animal in class Animal cannot be applied to given types".
• A cycle (A() calls this(1) which calls this()) is a compile error: "recursive constructor invocation".

Initialization order (verified)

This is the most-asked "what does this print?" question about classes. Here is a parent and child, each with a static field, a static block, an instance field, an instance block, and a constructor:

public class InitOrder {
    static class Parent {
        static String ps = log("1. Parent static field");
        static { log("2. Parent static block"); }
        String pf = log("5. Parent instance field");
        { log("6. Parent instance block"); }
        Parent() { log("7. Parent constructor"); }
    }
    static class Child extends Parent {
        static String cs = log("3. Child static field");
        static { log("4. Child static block"); }
        String cf = log("8. Child instance field");
        { log("9. Child instance block"); }
        Child() {
            super();                       // implicit if omitted
            log("10. Child constructor");
        }
    }
    static String log(String s) { System.out.println(s); return s; }

    public static void main(String[] args) {
        System.out.println("--- first new Child() ---");
        new Child();
        System.out.println("--- second new Child() ---");
        new Child();
    }
}

--- first new Child() ---
1. Parent static field
2. Parent static block
3. Child static field
4. Child static block
5. Parent instance field
6. Parent instance block
7. Parent constructor
8. Child instance field
9. Child instance block
10. Child constructor
--- second new Child() ---
5. Parent instance field
6. Parent instance block
7. Parent constructor
8. Child instance field
9. Child instance block
10. Child constructor

The rules behind it:

• Static initialisers run once, when the class is first initialised (first new, first static method call, or first access to a non-constant static field). Parent before child.
• Field initialisers and instance blocks are copied by the compiler into every constructor, right after the super(...) call. That is why they run after the parent constructor but before the rest of the child constructor.
• Within one level, field initialisers and blocks run in the order they appear in the source.
• A constructor that starts with this(...) does not re-run the field initialisers — only the constructor that calls super(...) does.

Common pitfalls

• Comparing objects with == checks identity. new Pizza() == new Pizza() is false even with equal fields; use equals (section 13).
• Calling an overridable method from a constructor lets a subclass run code before its own fields are set — you will see null (verified demo in section 10).
• Letting this "escape" from a constructor (registering it as a listener, starting a thread with it) exposes a half-built object to other code.

9. Encapsulation & Access Modifiers

The four access levels

Rules people forget

• A top-level class can only be public or package-private. Only nested classes can be private or protected. One public top-level class per file, and the file name must match it.
• private is per class, not per object. Inside Point, you can read other.x of another Point — that is how equals works. An outer class and its nested classes can also read each other's private members.
• protected includes package access. It is wider than package-private, not narrower — a common wrong answer.
• Interface members are public by default (methods are public abstract, fields are public static final).

The protected subtlety (verified with javac)

A subclass in a different package can use a protected member only through its own type (this, or a reference to itself or its subclasses) — not through a reference of the parent type.

// file com/shop/model/Account.java
package com.shop.model;
public class Account {
    public    String owner = "amy";   // everyone
    protected int    level = 1;       // same package + subclasses
              double rate  = 0.05;    // package-private
    private   long   balance = 100;   // this class only
    public long getBalance() { return balance; }
}

// file com/shop/web/Premium.java  -- a DIFFERENT package
package com.shop.web;
import com.shop.model.Account;
public class Premium extends Account {
    int myLevel()            { return level; }     // OK: inherited, via 'this'
    int viaSelf(Premium p)   { return p.level; }   // OK: reference is a Premium
    int viaParent(Account a) { return a.level; }   // ERROR
    double r()               { return rate; }      // ERROR
}

Premium.java:8: error: level has protected access in Account
Premium.java:9: error: rate is not public in Account; cannot be accessed from outside package

Why? A random Account could be some other company's subclass. Protected means "you may use the parts you inherited", not "you may poke into every Account". Meanwhile a class in com.shop.model (same package) can read a.level and a.rate freely.

Getters, setters and why encapsulation matters

Making fields private and adding a getter and setter for each one is not encapsulation by itself — it is a public field with extra steps. Real encapsulation means the class exposes behaviour and protects its invariants (rules that must always be true).

// Leaky: private field, but the getter hands out the internal list
class LeakyCart {
    private final List<String> items = new ArrayList<>();
    public List<String> getItems() { return items; }
}
LeakyCart cart = new LeakyCart();
cart.getItems().add("hacked");        // caller changed private state
cart.getItems();                      // [hacked]

// Encapsulated: validation inside, read-only view out
class BankAccount {
    private long balanceCents;
    private final List<String> history = new ArrayList<>();

    public long getBalanceCents() { return balanceCents; }       // read: fine

    public void deposit(long cents) {                            // no setBalance()!
        if (cents <= 0) throw new IllegalArgumentException("deposit must be positive");
        balanceCents += cents;
        history.add("+" + cents);
    }
    public void withdraw(long cents) {
        if (cents > balanceCents) throw new IllegalStateException("insufficient funds");
        balanceCents -= cents;
        history.add("-" + cents);
    }
    public List<String> getHistory() { return Collections.unmodifiableList(history); }
}
acc.deposit(500); acc.withdraw(200);
acc.getBalanceCents() + " " + acc.getHistory();   // 300 [+500, -200]
acc.withdraw(10_000);                             // IllegalStateException: insufficient funds
acc.getHistory().add("+1000000");                 // UnsupportedOperationException

Best practice

• Make every field private (and final if it never changes). Widen only when you have a reason.
• Prefer intention-revealing methods (withdraw, markShipped) over raw setters. "Tell, don't ask."
• Never return an internal mutable collection or array. Return an unmodifiable view, a copy, or List.copyOf.
• For pure data carriers, a record (section 15) gives private final fields and accessors for free.

10. Inheritance

extends, super and overriding

class Animal {
    protected String name;
    Animal(String name) { this.name = name; }
    String sound()    { return "..."; }
    String describe() { return name + " says " + sound(); }
    Animal reproduce() { return new Animal(name + " Jr"); }
    void save() throws IOException { }
    final String kingdom() { return "Animalia"; }       // cannot be overridden
}

class Dog extends Animal {
    Dog(String name) { super(name); }                    // parent constructor first
    @Override String sound() { return "Woof"; }
    @Override String describe() { return super.describe() + "!"; }   // reuse parent code
    @Override Dog reproduce() { return new Dog(name + " Jr"); }      // covariant return
    @Override public void save() throws FileNotFoundException { }    // wider access, narrower exception
}

Animal a = new Dog("Rex");
a.describe();                       // "Rex says Woof!"  -- parent code calls the CHILD's sound()
Dog pup = new Dog("Rex").reproduce();  // no cast needed thanks to the covariant return
pup.name + " " + pup.kingdom();     // "Rex Jr Animalia"

super.method() calls the parent's version; super(...) calls the parent's constructor. super.super.x() does not exist.

Method overriding rules

The reasoning is the Liskov substitution principle: code written against Animal must keep working when handed a Dog. A narrower access or a new checked exception would break that caller. Here is what javac says when you break the rules:

class Dog extends Animal {
    String sound() { return "Woof"; }    // parent's is public
    void save() throws Exception { }     // parent throws IOException
    String kingdom() { return "x"; }     // parent's is final
}
final class Money { }
class Coins extends Money { }

error: sound() in Dog cannot override sound() in Animal
  attempting to assign weaker access privileges; was public
error: save() in Dog cannot override save() in Animal
  overridden method does not throw Exception
error: kingdom() in Dog cannot override kingdom() in Animal
  overridden method is final
error: cannot inherit from final Money

Always write @Override. If you misspell the name or get a parameter type wrong (equals(Point p) instead of equals(Object o)), the annotation turns a silent overload into a compile error.

final classes and methods

• A final method cannot be overridden: use it when the parent's logic must not change (security checks, template-method skeletons).
• A final class cannot be extended: String, Integer and all wrappers, LocalDate, every record. This guarantees nobody can create a "String" subclass that mutates or lies about its contents.
• Java 17 adds a middle ground: sealed classes list exactly which subclasses are allowed (section 12).

Why no multiple class inheritance: the diamond problem

Java refuses class D extends B, C to avoid this ambiguity about both behaviour and state. Interfaces had no state and no code, so implementing many was always safe. Java 8 default methods brought code into interfaces, so the diamond came back for methods (never for fields). The resolution rules are:

1. Class wins. A method in the class or any superclass beats any interface default.
2. More specific interface wins. If B extends A and both have a default, B's is used.
3. Otherwise you must override it, and you may pick one with X.super.method().

interface Swimmer { default String move() { return "swim"; } }
interface Flyer   { default String move() { return "fly"; } }

class Duck implements Swimmer, Flyer {
    @Override public String move() {               // required: otherwise compile error
        return Swimmer.super.move() + " + " + Flyer.super.move();
    }
}
new Duck().move();   // "swim + fly"
// Without the override:
// error: types Swimmer and Flyer are incompatible;
//   class Duck inherits unrelated defaults for move() from types Swimmer and Flyer

Pitfall: overridable method called from a constructor

class Base {
    Base() { System.out.println("Base ctor sees: " + label()); }
    String label() { return "base"; }
}
class Derived extends Base {
    private String tag = "derived";          // assigned AFTER Base() finishes
    @Override String label() { return tag; }
}
new Derived();   // prints "Base ctor sees: null"

Dynamic dispatch works even inside the parent's constructor, so Derived.label() runs before tag is initialised (see the order in section 8). Rule: constructors should call only private, final or static methods.

Composition over inheritance

Inheritance couples you to the parent's implementation, not just its contract. The famous example from Effective Java: count how many elements were ever added to a set.

class CountingSet<E> extends HashSet<E> {
    int added = 0;
    @Override public boolean add(E e) { added++; return super.add(e); }
    @Override public boolean addAll(Collection<? extends E> c) {
        added += c.size(); return super.addAll(c);
    }
}
s.addAll(List.of("a", "b", "c"));
s.added;   // 6, not 3 -- HashSet.addAll() internally calls add() for each element

class CountingSet2<E> {                           // composition: HAS-A set
    private final Set<E> inner = new HashSet<>();
    int added = 0;
    boolean add(E e) { added++; return inner.add(e); }
    boolean addAll(Collection<? extends E> c) { added += c.size(); return inner.addAll(c); }
}
s2.added;  // 3

This is the fragile base class problem. Use inheritance for a true IS-A relationship where the parent was designed to be extended; otherwise wrap an object and delegate to it.

11. Polymorphism

Overloading vs overriding

One demo, all the rules (verified)

class Shape {
    String name = "shape";                          // field
    static String kind() { return "Shape.kind"; }   // static
    String draw() { return "drawing a shape"; }     // instance
}
class Circle extends Shape {
    String name = "circle";                         // HIDES Shape.name (a second field)
    static String kind() { return "Circle.kind"; }  // HIDES Shape.kind()
    @Override String draw() { return "drawing a circle"; }
    double radius() { return 1.0; }
}
class Square extends Shape {
    @Override String draw() { return "drawing a square"; }
}

static String greet(Shape s)  { return "greet(Shape)"; }
static String greet(Circle c) { return "greet(Circle)"; }

Shape s = new Circle();        // upcast: implicit, always safe
s.draw();                      // "drawing a circle"  -- runtime type decides
s.name;                        // "shape"             -- fields: declared type decides
((Circle) s).name;             // "circle"
s.kind();                      // "Shape.kind"        -- static: declared type decides
greet(s);                      // "greet(Shape)"      -- overload chosen at compile time

• Only instance methods are polymorphic. Fields and static methods are resolved from the declared type of the variable. A subclass field with the same name is a second, separate field (field hiding) — avoid it.
• Static methods are hidden, not overridden. Calling a static method through an instance compiles but javac -Xlint warns: "static method should be qualified by type name, Shape, instead of by an expression".
• Overload choice is fixed at compile time: greet(s) picks greet(Shape) even though s holds a Circle. Overloading does not dispatch on runtime type.

How dynamic dispatch works inside

HotSpot calls this the vtable (virtual method table); interfaces use a similar itable. The JIT compiler often removes the lookup entirely: if only one class is ever seen at a call site, it inlines that method directly ("monomorphic inline cache"), so polymorphism is effectively free in hot code.

Overload resolution order

When several overloads could match, the compiler tries in three phases and stops at the first that works:

1. Exact match or widening of primitives (int → long), no boxing.
2. Boxing / unboxing (int → Integer).
3. Varargs.

static String pick(long x)    { return "long (widening)"; }
static String pick(Integer x) { return "Integer (boxing)"; }
static String pick(int... x)  { return "varargs"; }
pick(5);   // "long (widening)" -- widening beats boxing beats varargs

If two overloads are equally good (for example f(String) and f(Integer) called with null), it is a compile error: "reference to f is ambiguous".

Upcasting, downcasting and pattern matching

Shape[] shapes = { new Circle(), new Square(), new Shape() };
for (Shape sh : shapes) sh.draw();   // circle, square, shape -- one loop, many forms

Shape sq = new Square();
Circle c = (Circle) sq;              // compiles, but throws ClassCastException at run time

// Java 16+: instanceof with a pattern variable -- test and cast in one step
if (s instanceof Circle c && c.radius() > 0) {
    System.out.println("radius " + c.radius());   // radius 1.0
}

// Java 21: pattern matching for switch
String out = switch (sh) {
    case Circle c -> "circle r=" + c.radius();
    case Square q -> "square";
    default       -> "plain shape";
};
// circle r=1.0, square, plain shape

• Upcast (child to parent) is automatic and always safe; you only lose access to child-only methods.
• Downcast (parent to child) needs an explicit cast and is checked at run time. Casting between unrelated classes ((String) someInteger) is a compile error.
• Order matters in a pattern switch: a case Shape s placed before case Circle c is a compile error ("this case label is dominated by a preceding case label").
• A long instanceof chain is often a sign that the behaviour belongs in an overridden method. Pattern switches shine over sealed hierarchies and records (section 12, 15), where the compiler checks you covered every case.

12. Abstract Classes vs Interfaces

Side by side

Abstract class: shared state and a template method

abstract class Report {
    private final String title;                    // state lives here
    protected Report(String title) { this.title = title; }

    public final String render() {                 // template method: the fixed skeleton
        return "== " + title + " ==\n" + body() + "\n-- end --";
    }
    protected abstract String body();              // the step subclasses fill in
}

class SalesReport extends Report {
    SalesReport() { super("Sales"); }
    @Override protected String body() { return "total: 42"; }
}

System.out.println(new SalesReport().render());
// == Sales ==
// total: 42
// -- end --

A class with even one abstract method must itself be abstract. An abstract class may have zero abstract methods — that just stops people instantiating it. An abstract method cannot be private, static or final (each would make overriding impossible).

Interface: Java 8 default and static, Java 9 private

interface Discount {
    double apply(double price);                    // abstract

    default double applyTwice(double price) {      // Java 8: implementers inherit this
        return round(apply(apply(price)));
    }
    static Discount percent(double p) {            // Java 8: factory, called as Discount.percent(..)
        return price -> price * (1 - p / 100);
    }
    private double round(double v) {               // Java 9: helper hidden from implementers
        return Math.round(v * 100) / 100.0;
    }
    int MAX_PERCENT = 90;                          // implicitly public static final
}

Discount tenOff = Discount.percent(10);
tenOff.apply(200);         // 180.0
tenOff.applyTwice(99.99);  // 80.99
Discount.MAX_PERCENT;      // 90

Why default methods exist: Java 8 wanted to add stream() and forEach() to Collection. Adding an abstract method would have broken every existing implementation in the world; a default method gives them a working version for free. Static interface methods are not inherited by implementing classes — you must call Discount.percent(...).

Java 17: sealed interfaces

sealed interface Payment permits Card, Upi, Cash {}
record Card(String number) implements Payment {}
record Upi(String vpa)     implements Payment {}
record Cash()              implements Payment {}

static String fee(Payment p) {
    return switch (p) {                            // exhaustive: no default needed (Java 21)
        case Card c -> "2% card fee";
        case Upi u  -> "no fee for " + u.vpa();
        case Cash c -> "no fee";
    };
}
// 2% card fee / no fee for amy@bank / no fee

Every permitted subtype must be final (records are), sealed, or non-sealed. Because the compiler knows the full list, a pattern switch needs no default; add a fourth payment type and every switch that forgot it stops compiling. This is Java's version of an algebraic data type.

Which one to pick

• Default to an interface. It defines a type without locking callers into a hierarchy, and a class can mix in several (Comparable, Serializable, AutoCloseable).
• Use an abstract class when subclasses genuinely share state or constructor logic, or you need non-public members, or a template method with a fixed skeleton (AbstractList, HttpServlet).
• A common combination: an interface for the type plus an abstract "skeletal implementation" (List + AbstractList). Callers depend on the interface; implementers extend the skeleton to save work.
• Use sealed when the set of subtypes is closed and known (payment kinds, AST nodes, results like Success / Failure).

13. The Object Class: equals, hashCode, toString

Methods every object has

The equals contract

• Reflexive: x.equals(x) is true.
• Symmetric: x.equals(y) if and only if y.equals(x).
• Transitive: if x.equals(y) and y.equals(z), then x.equals(z).
• Consistent: the answer does not change unless the objects change.
• Non-null: x.equals(null) is false (never throws).

The hashCode contract

• If a.equals(b), then a.hashCode() == b.hashCode(). This is the one that matters.
• Equal hash codes do not require equal objects (collisions are allowed, just slower).
• The value must stay the same while the fields used in equals do not change.

Broken HashSet: equals without hashCode (verified)

class BadPoint {
    final int x, y;
    BadPoint(int x, int y) { this.x = x; this.y = y; }
    @Override public boolean equals(Object o) {
        return o instanceof BadPoint p && x == p.x && y == p.y;
    }
    // no hashCode()!
}
Set<BadPoint> bad = new HashSet<>();
bad.add(new BadPoint(1, 2));
bad.add(new BadPoint(1, 2));
new BadPoint(1, 2).equals(new BadPoint(1, 2));   // true
bad.size();                                      // 2   -- a "duplicate" got in
bad.contains(new BadPoint(1, 2));                // false -- can't find an equal element

A correct equals and hashCode

final class Point {
    private final int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }

    @Override public boolean equals(Object o) {
        if (this == o) return true;                    // fast path
        if (!(o instanceof Point p)) return false;     // also handles null
        return x == p.x && y == p.y;
    }
    @Override public int hashCode() { return Objects.hash(x, y); }
    @Override public String toString() { return "Point(" + x + ", " + y + ")"; }
}
good.add(new Point(1, 2)); good.add(new Point(1, 2));
good.size();                       // 1
good.contains(new Point(1, 2));    // true
good;                              // [Point(1, 2)]

• The parameter must be Object. equals(Point p) is an overload; collections call equals(Object) and never see it. @Override catches this.
• Compare double fields with Double.compare, objects with Objects.equals(a, b) (null-safe), arrays with Arrays.equals.
• instanceof vs getClass(): with instanceof, a subclass that adds a field (ColorPoint) breaks symmetry — point.equals(colorPoint) is true but not the reverse. Either make the class final (as above) or use getClass() != o.getClass(), which treats subclasses as never equal.
• Records (section 15) generate a correct equals, hashCode and toString from their components.

Mutable keys: the other way to lose an entry

Set<Tag> tags = new HashSet<>();
Tag t = new Tag("java");            // equals/hashCode use 'name'
tags.add(t);
t.name = "kotlin";                  // mutate AFTER inserting
tags.contains(t);                   // false -- looks in the bucket for "kotlin"
tags.size();                        // 1     -- the entry is stuck in the "java" bucket

Never change a field that equals/hashCode use while the object is a key in a map or an element of a set. The safest fix: make keys immutable (String, records, enums).

toString

The default prints ObjectMethods$BadPoint@ followed by a hex hash — useless in a log. Override it for any class you will ever print or debug. Keep it cheap, never throw from it, and never include secrets (passwords, tokens), because logs end up everywhere.

clone: shallow vs deep

class Team implements Cloneable {
    String name;
    List<String> members = new ArrayList<>();
    @Override public Team clone() {
        try { return (Team) super.clone(); }          // copies fields one by one
        catch (CloneNotSupportedException e) { throw new AssertionError(e); }
    }
    Team deepCopy() {                                 // copy-constructor style
        Team t = new Team(name);
        t.members = new ArrayList<>(members);        // NEW list with the same elements
        return t;
    }
}
a.members.add("amy");
Team shallow = a.clone(), deep = a.deepCopy();
shallow.members.add("bob");
a.members + " " + shallow.members + " " + deep.members;   // [amy, bob] [amy, bob] [amy]
a.members == shallow.members;                             // true -- one shared list

Cloneable is widely considered a broken design: it is a marker interface with no clone method, Object.clone skips constructors, and it does not work with final fields that need a fresh copy. Prefer a copy constructor (new Team(other)) or a static factory (Team.copyOf(other)). Arrays are the exception: array.clone() is fine (and shallow).

14. Nested, Inner & Anonymous Classes

The four kinds

All four in one program (verified)

public class Nested {
    private int outerValue = 10;
    private static int counter = 0;

    static class StaticNested {                  // no link to a Nested object
        int read() { return counter; }           // only static members
    }
    class Inner {                                // tied to one Nested object
        int outerValue = 20;
        int read() { return outerValue + Nested.this.outerValue; }   // 20 + 10
    }

    Runnable localAndAnonymous(String prefix) {
        int base = 5;                            // effectively final
        class Local {                            // visible only inside this method
            String show() { return prefix + (base + outerValue); }
        }
        return new Runnable() {                  // anonymous class
            @Override public void run() {
                System.out.println(new Local().show() + ", anon class = " + this.getClass().getName());
            }
        };
    }
    Runnable lambda() {
        return () -> System.out.println("lambda this is outer? " + (this.getClass() == Nested.class));
    }

    public static void main(String[] args) {
        Nested outer = new Nested();
        StaticNested sn = new Nested.StaticNested();     // no outer instance needed
        Nested.Inner in = outer.new Inner();             // needs an outer instance
        System.out.println(sn.read() + " " + in.read()); // 0 30
        outer.localAndAnonymous("sum=").run();           // sum=15, anon class = Nested$1
        outer.lambda().run();                            // lambda this is outer? true
    }
}

• Nested.this.outerValue reaches the outer field when the inner class shadows the name.
• Anonymous classes compile to Outer$1, Outer$2 …; nested ones to Outer$Inner.
• Inside an anonymous class, this is the anonymous object. Inside a lambda, this is the enclosing object — a lambda is not a class of its own and does not introduce a new scope.
• Local and anonymous classes (and lambdas) can use a local variable only if it is effectively final (never reassigned). Adding base++ gives "local variables referenced from an inner class must be final or effectively final". The value is copied into the object, so allowing changes would create two versions that drift apart.
• Since Java 16, inner classes may declare static members, and you can declare local records, enums and interfaces.

The hidden reference and memory leaks

The compiler gives every inner class that uses its outer object a hidden field, this$0, pointing to that object. Reflection shows it:

for (Field f : Inner.class.getDeclaredFields())
    System.out.println("Inner field: " + f.getName() + (f.isSynthetic() ? " (synthetic)" : ""));
// Inner field: outerValue
// Inner field: this$0 (synthetic)      <-- reference to the outer object

class Unused { int x; }                  // an inner class that never touches Outer
// Unused fields: [x]                    -- javac 18+ drops this$0 when it is not used
StaticNested.class.getDeclaredFields().length;   // 0 -- no outer reference at all

• Rule of thumb (Effective Java): if a nested class does not need the outer instance, make it static. It is smaller, cannot leak, and can be created without an outer object.
• Anonymous classes created in instance methods can capture this too. A lambda captures this only if its body actually uses an instance member.
• Inner-class objects are also a serialization trap: serializing one drags in the outer object.

Where each one shows up

• Static nested: Builder in the builder pattern, Map.Entry, the lazy holder idiom for singletons (section 16), private node classes (LinkedList.Node).
• Inner: ArrayList.Itr — the iterator needs the list's array and size.
• Anonymous: pre-Java 8 callbacks (new Comparator<>() {...}), or when you need to implement an interface with several methods or extend an abstract class inline.
• Lambda: the modern replacement for anonymous classes of functional interfaces (section 24).

15. Enums & Records

Enums are classes

enum Planet {
    MERCURY(3.303e+23, 2.4397e6),
    EARTH(5.976e+24, 6.37814e6);                    // constants first, then a semicolon

    private final double mass, radius;              // fields
    Planet(double mass, double radius) {            // constructor is always private
        this.mass = mass; this.radius = radius;
    }
    double surfaceGravity() { return 6.67300E-11 * mass / (radius * radius); }
}
Planet.EARTH.surfaceGravity();                      // 9.80 (printed with %.2f)

// Constant-specific bodies: each constant has its own implementation
enum Op {
    PLUS("+")  { int apply(int a, int b) { return a + b; } },
    TIMES("*") { int apply(int a, int b) { return a * b; } };
    final String symbol;
    Op(String symbol) { this.symbol = symbol; }
    abstract int apply(int a, int b);
}
Op.TIMES.apply(6, 7);                               // 42

Built-in methods, switch and the enum collections

enum Day { MON, TUE, WED, THU, FRI, SAT, SUN }

Day.valueOf("WED").ordinal();     // 2   (position, starting at 0)
Day.values().length;              // 7
Day.FRI.name();                   // "FRI"
Day.SAT.compareTo(Day.MON);       // 5   (compares ordinals)
Day.valueOf("Funday");            // IllegalArgumentException

String type = switch (d) {        // case labels are written WITHOUT "Day."
    case SAT, SUN -> "weekend";
    default       -> "weekday";
};                                // "weekend" for SAT

EnumMap<Day, Integer> hours = new EnumMap<>(Day.class);
hours.put(Day.FRI, 6); hours.put(Day.MON, 8);
hours;                            // {MON=8, FRI=6}  -- always in declaration order
EnumSet.range(Day.MON, Day.WED);  // [MON, TUE, WED]

• EnumMap is backed by a plain array indexed by ordinal, and EnumSet by a bit mask (one long for up to 64 constants). Both are faster and smaller than HashMap/HashSet — always prefer them for enum keys.
• Compare enums with ==: it is null-safe and each constant exists exactly once.
• Never persist ordinal() (in a database or file). Inserting a new constant in the middle shifts every number. Store name() or an explicit code field.
• A switch over an enum in a switch expression (Java 14) must be exhaustive; if you list every constant, no default is needed.

Singleton via enum

enum IdGenerator {
    INSTANCE;
    private long next = 1;
    synchronized long nextId() { return next++; }
}
IdGenerator.INSTANCE.nextId();   // 1
IdGenerator.INSTANCE.nextId();   // 2

Effective Java calls this the best way to write a singleton: the JVM guarantees exactly one instance, creation is thread-safe, serialization cannot create a second copy, and reflection cannot call the constructor (Constructor.newInstance refuses enum types). Its only limit: an enum cannot extend another class.

Records (Java 16)

record Money(long cents, String currency) {
    Money {                                        // COMPACT constructor: no parameter list
        if (cents < 0) throw new IllegalArgumentException("negative: " + cents);
        currency = currency.toUpperCase();         // reassign the PARAMETER; fields set after
    }
    Money add(Money o) { return new Money(cents + o.cents, currency); }   // returns a new object
    static Money zero(String cur) { return new Money(0, cur); }
}

Money m = new Money(500, "usd");
m;                                  // Money[cents=500, currency=USD]
m.cents();                          // 500   -- accessor is cents(), not getCents()
m.equals(new Money(500, "USD"));    // true  -- compares all components
m.add(Money.zero("usd")) == m;      // false -- a new object every time
new Money(-1, "usd");               // IllegalArgumentException: negative: -1

• The compact constructor is for validation and normalisation. The assignments this.cents = cents are added automatically at the end, so you work on the parameters.
• A record may add methods, static fields and static factories, and implement interfaces. It may not declare extra instance fields or extend a class.
• Records are shallowly immutable. A List component can still be changed by whoever holds that list — copy it:

  record Team(String name, List<String> members) {
      Team { members = List.copyOf(members); }       // defensive copy, also unmodifiable
  }
  List<String> src = new ArrayList<>(List.of("amy"));
  Team t = new Team("core", src);
  src.add("bob");
  t;                                                 // Team[name=core, members=[amy]]

• Java 21 record patterns destructure them: if (obj instanceof Money(long c, String cur)) ... or case Money(var c, var cur) -> ... in a switch.

When not to use a record

• JPA / Hibernate entities — they need a no-arg constructor, mutable fields and proxies (subclasses). Records fit DTOs and query projections instead.
• The object must change over time, or has identity beyond its values (two users with the same name are still two users).
• You need to hide some state, compute lazy/cached fields, or extend a base class.
• The public API would lock you in: every component becomes a public accessor and part of equals, and renaming one breaks callers.

16. static, final & Immutability

static in all its forms

public class StaticDemo {
    static final int MAX = 100;                         // compile-time constant (inlined by javac)
    static final Map<String, Integer> CODES;
    static {                                            // runs once, on first use of the class
        CODES = Map.of("IN", 91, "US", 1);
        System.out.println("StaticDemo initialised");
    }
    static class Holder {                               // lazy, thread-safe singleton idiom
        static { System.out.println("Holder initialised"); }
        static final StaticDemo INSTANCE = new StaticDemo();
    }
    static StaticDemo get() { return Holder.INSTANCE; }

    public static void main(String[] args) {
        System.out.println("main starts, MAX = " + MAX + ", IN = " + CODES.get("IN"));
        System.out.println(get() == get());
    }
}
// StaticDemo initialised
// main starts, MAX = 100, IN = 91
// Holder initialised           <-- only when get() is first called
// true

The holder idiom works because the JVM initialises a class lazily and under a lock: Holder is not touched until get() runs, and the JVM guarantees its static initialiser runs exactly once, even with many threads.

• A static method cannot use instance state: static void f() { count++; } gives "non-static variable count cannot be referenced from a static context".
• Static fields live with the class (in the Class object on the heap in modern HotSpot), so a static List or Map that keeps growing is a classic memory leak — it is never garbage collected while the class is loaded.
• Static mutable state is global state: hard to test, and shared by all threads. Prefer constants (static final) and pass everything else in.

final in all its forms

final List<String> names = new ArrayList<>();
names.add("still mutable");          // allowed -- the OBJECT changes, the reference does not
names = new ArrayList<>();           // error: cannot assign a value to final variable names

int limit = 3;                       // never reassigned -> EFFECTIVELY FINAL (Java 8)
Runnable r = () -> System.out.println("limit " + limit);   // OK, prints "limit 3"
// adding limit++ anywhere gives:
// error: local variables referenced from a lambda expression must be final or effectively final

final reference is not an immutable object. final freezes the arrow, not the thing it points to. This is the single most common confusion in this topic.

How to build an immutable class: the checklist

1. Make the class final (or give it only private constructors), so no subclass can add mutable state or override accessors.
2. Make every field private final.
3. Provide no setters and no methods that change fields.
4. Defensive copy in: copy every mutable argument (lists, arrays, Date) in the constructor.
5. Defensive copy out: never return a mutable internal object; return a copy or an unmodifiable view.
6. "Modifying" methods return a new object (withItem, plusDays).
7. Do not let this escape from the constructor.

// BROKEN: final fields, but it holds the caller's mutable objects
final class LeakyOrder {
    private final List<String> items;
    private final Date placedAt;
    LeakyOrder(List<String> items, Date placedAt) { this.items = items; this.placedAt = placedAt; }
    List<String> items() { return items; }
    Date placedAt() { return placedAt; }
}

// CORRECT
public final class Order {                                 // 1. final class
    private final String id;                               // 2. private final fields
    private final List<String> items;
    private final Date placedAt;

    public Order(String id, List<String> items, Date placedAt) {
        this.id = Objects.requireNonNull(id);
        this.items = List.copyOf(items);                   // 4. copy in (and unmodifiable)
        this.placedAt = new Date(placedAt.getTime());      //    copy the mutable Date
    }
    public String id() { return id; }                      // 3. no setters
    public List<String> items() { return items; }          //    already unmodifiable: safe
    public Date placedAt() { return new Date(placedAt.getTime()); }  // 5. copy out
    public Order withItem(String item) {                   // 6. change = new object
        List<String> next = new ArrayList<>(items);
        next.add(item);
        return new Order(id, next, placedAt);
    }
}

The same attack on both — mutate the caller's list and date after construction, mutate what the getters return:

list.add("HACK"); when.setTime(999_999_999_999L); leaky.items().add("HACK2");
leaky.items() + " " + leaky.placedAt().getTime();   // [pen, HACK, HACK2] 999999999999

list.add("HACK"); when.setTime(999_999_999_999L); order.placedAt().setTime(123);
order.items().add("HACK2");                         // UnsupportedOperationException
order.items() + " " + order.placedAt().getTime();   // [pen] 0
order.withItem("ink").items();                      // [pen, ink]  -- order itself is still [pen]

Better still, avoid mutable parts altogether: use Instant or LocalDate (immutable, Java 8) instead of Date, and a record with a compact constructor for the copying.

Why immutability is worth it

• Thread-safe for free — nothing changes, so no locks are needed.
• Safe map keys and set elements — the hash code can never change under the collection (see the mutable-key bug in section 13).
• Easy to reason about and cache — share one instance everywhere (String pool, Integer cache, BigDecimal.ZERO).
• Cost: more objects created on each "change". Modern GCs handle short-lived objects cheaply; for heavy building, use a mutable builder (StringBuilder) and freeze at the end.

Why is String immutable? So it can be shared from the string pool, used safely as a HashMap key (its hash is cached), passed across threads without locking, and trusted in security checks (a file path or class name cannot change after it is validated).

17. Exceptions

The hierarchy

try / catch / finally — the exact rules

• catch blocks are tried top to bottom; the first matching type wins. A subclass catch must come before its superclass catch, or the compiler rejects it as unreachable.
• finally runs whether the try block finished normally, returned, or threw. It is for cleanup.
• If the try block executes return x, the value of x is saved first, then finally runs. Changing a primitive in finally does not change the returned value — but mutating a returned object does.
• A return inside finally overrides the try's return and even swallows an exception in flight. Never do it.

@SuppressWarnings("finally")
static int returnInFinally() {
    try { return 1; } finally { return 2; }
}                                          // returns 2

@SuppressWarnings("finally")
static String swallow() {
    try { throw new IllegalStateException("lost!"); }
    finally { return "finally won"; }      // the exception silently disappears
}                                          // returns "finally won"

static int captured() {
    int x = 10;
    try { return x; } finally { x = 20; }  // 10 was already saved
}                                          // returns 10

static List<String> capturedRef() {
    List<String> list = new ArrayList<>();
    try { list.add("try"); return list; }
    finally { list.add("finally"); }       // same object, so the change shows
}                                          // returns [try, finally]

When does finally NOT run?

public static void main(String[] args) {
    try {
        System.out.println("in try");
        System.exit(0);                    // JVM starts shutting down right here
    } finally {
        System.out.println("finally");     // never printed
    }
}
// Output: in try

finally is skipped when the JVM itself stops: System.exit(), Runtime.halt(), a crash, the process being killed (kill -9), or a power cut. It also never runs if the try block never ends (infinite loop, deadlock), and a daemon thread's finally is skipped when the JVM exits. Shutdown hooks (Runtime.addShutdownHook) run on System.exit, but finally blocks do not.

try-with-resources (Java 7) and suppressed exceptions

Any object that implements AutoCloseable can be declared in the try header. Java closes it automatically, in reverse order of declaration, even if the body throws. If close() also throws, that exception is not lost and does not hide the real one: it is attached to the main exception as a suppressed exception.

static class Res implements AutoCloseable {
    private final String name;
    Res(String name) { this.name = name; System.out.println("open " + name); }
    @Override public void close() throws IOException {
        System.out.println("close " + name);
        throw new IOException("close failed: " + name);
    }
}

try (Res a = new Res("A"); Res b = new Res("B")) {
    System.out.println("body");
    throw new IllegalStateException("body failed");
} catch (Exception e) {
    System.out.println("caught: " + e.getMessage());
    for (Throwable s : e.getSuppressed())
        System.out.println("  suppressed: " + s.getMessage());
}
// open A
// open B
// body
// close B                         <- reverse order
// close A
// caught: body failed             <- the REAL error wins
//   suppressed: close failed: B
//   suppressed: close failed: A

With the old try/finally style, an exception from close() in finally would replace the body's exception, and you would debug the wrong problem. Since Java 9 you can also use an existing effectively-final variable: try (reader) { ... }.

Multi-catch (Java 7)

for (String in : new String[]{"abc", null}) {
    try {
        System.out.println(Integer.parseInt(in.trim()));
    } catch (NumberFormatException | NullPointerException e) {
        System.out.println("multi-catch: " + e.getClass().getSimpleName());
    }
}
// multi-catch: NumberFormatException
// multi-catch: NullPointerException

The variable e is implicitly final. The alternatives cannot be parent and child (IOException | FileNotFoundException does not compile — the parent already covers the child).

Custom exceptions and chaining

// Checked: the caller is expected to recover (show a message, retry with less)
class InsufficientFundsException extends Exception {
    private final long shortBy;
    InsufficientFundsException(String msg, long shortBy) { super(msg); this.shortBy = shortBy; }
    long shortBy() { return shortBy; }       // extra data the handler can use
}

// Unchecked wrapper that keeps the original as its CAUSE
class DataAccessException extends RuntimeException {
    DataAccessException(String msg, Throwable cause) { super(msg, cause); }
}

try {
    throw new SQLException("connection refused");
} catch (SQLException e) {
    throw new DataAccessException("could not load user 42", e);   // chain, don't drop
}
// e.getMessage()            -> could not load user 42
// e.getCause().getMessage() -> connection refused

Exception chaining means wrapping a low-level exception in a higher-level one while keeping the original as the cause. The stack trace then shows both, with a Caused by: line. Translating exceptions at layer boundaries (SQL error becomes a "data access" error) keeps the upper layers independent of JDBC details — Spring does exactly this.

final vs finally vs finalize

Best practices

• Catch specific types, not Exception or Throwable, except at a top-level boundary (a request handler, a thread's run loop) where you log and return an error.
• Never swallow: an empty catch {} hides bugs. At least log it; usually rethrow or wrap.
• Keep the cause when wrapping: new XException("context", e). Losing the original stack trace is the most common logging mistake.
• Log or rethrow, not both — doing both prints the same error many times up the stack.
• Don't use exceptions for normal control flow. Creating one fills in a stack trace, which is slow compared to an if.
• Fail fast with clear messages: Objects.requireNonNull(user, "user must not be null"), IllegalArgumentException for bad arguments, IllegalStateException for "wrong time to call this".
• If you catch InterruptedException and cannot rethrow it, restore the flag: Thread.currentThread().interrupt().
• Prefer unchecked exceptions for application errors in modern code (Spring, most libraries); use checked only when the caller can realistically recover.

18. Generics

Why generics: before and after

// Before Java 5: everything is Object, casts everywhere, errors at runtime
List names = new ArrayList();
names.add("amy");
names.add(42);                     // compiler happy
String s = (String) names.get(1);  // ClassCastException at runtime

// With generics: the mistake is a compile error
List<String> typed = new ArrayList<>();   // diamond <> since Java 7
typed.add("amy");
// typed.add(42);                  // does not compile
String t = typed.get(0);           // no cast

Generic classes, methods and bounded types

class Box<T> {                          // T = type parameter
    private T value;
    Box(T value) { this.value = value; }
    T get() { return value; }
}
Box<String> b = new Box<>("hi");
String s = b.get();                      // "hi", no cast

// Generic METHOD: the <T> before the return type declares it
static <T> T firstOrNull(List<T> list) { return list.isEmpty() ? null : list.get(0); }
firstOrNull(List.of("x", "y"));          // T inferred as String -> "x"
GenDemo.<String>firstOrNull(List.of("x"));   // explicit "type witness", rarely needed

// BOUNDED type: T must be Comparable, so compareTo is allowed
static <T extends Comparable<T>> T max(List<T> list) {
    T best = list.get(0);
    for (T t : list) if (t.compareTo(best) > 0) best = t;
    return best;
}
max(List.of(3, 9, 4));                   // 9
max(List.of("pear", "apple", "zucchini")); // "zucchini"

Naming convention: T type, E element, K/V key/value, R result. Multiple bounds use &: <T extends Number & Comparable<T>> (a class first, then interfaces). The JDK's own signature is the more flexible <T extends Comparable<? super T>>, so it also works when a parent class implements Comparable.

Invariance: why List<Integer> is not a List<Number>

Even though Integer is a Number, a List<Integer> is not a List<Number> (generics are invariant). If it were, you could add a Double into a list of Integers through the List<Number> reference. Arrays made the opposite choice (they are covariant) and pay for it at runtime:

Integer[] ia = {1, 2};
Object[] oa = ia;          // allowed: arrays are covariant
oa[0] = "boom";            // compiles, but throws ArrayStoreException: java.lang.String

List<Integer> ints = List.of(1, 2, 3);
// List<Number> nums = ints;   // compile error: generics catch it earlier

Wildcards and PECS

A wildcard ? means "some type I don't know". Bounded wildcards restore flexibility safely:

PECS: Producer Extends, Consumer Super. If a parameter gives you values, use extends; if it takes values from you, use super. If it does both, use a plain T.

static double sum(List<? extends Number> nums) {   // PRODUCER: we only read
    double s = 0;
    for (Number n : nums) s += n.doubleValue();
    return s;
}
sum(List.of(1, 2, 3));          // 6.0
sum(List.of(1.5, 2.5));         // 4.0

static void addInts(List<? super Integer> sink) {  // CONSUMER: we only write
    sink.add(1); sink.add(2);
}
addInts(new ArrayList<Number>());   // [1, 2]
addInts(new ArrayList<Object>());   // [1, 2]

// Both at once -- the shape of Collections.copy
static <T> void copy(List<? super T> dst, List<? extends T> src) {
    for (T t : src) dst.add(t);
}
List<Object> dst = new ArrayList<>(List.of("start"));
copy(dst, List.of(1, 2, 3));    // [start, 1, 2, 3]

JDK examples: Collections.max(Collection<? extends T>, Comparator<? super T>), list.sort(Comparator<? super E>) — a Comparator<Object> can sort a List<String>.

Type erasure and its consequences

After checking, the compiler replaces each type parameter with its bound (Object if unbounded, or the first bound), and inserts casts where you read values. One compiled class serves all type arguments.

List<String> ls = new ArrayList<>();
List<Integer> li = new ArrayList<>();
ls.getClass() == li.getClass();     // true -- both are java.util.ArrayList at runtime

// Workaround for new T(): pass a factory
static <T> List<T> fill(int n, Supplier<T> factory) {
    List<T> out = new ArrayList<>();
    for (int i = 0; i < n; i++) out.add(factory.get());
    return out;
}
fill(3, StringBuilder::new);        // 3 new StringBuilders

Bridge methods

When a class implements a generic interface with a concrete type, erasure would break overriding: Comparable<T>.compareTo(T) erases to compareTo(Object), but your class declares compareTo(Name). The compiler adds a hidden bridge method compareTo(Object) that casts and calls yours. You can see it with reflection:

class Name implements Comparable<Name> {
    final String s; Name(String s) { this.s = s; }
    public int compareTo(Name o) { return s.compareTo(o.s); }
}
for (Method m : Name.class.getDeclaredMethods())
    if (m.getName().equals("compareTo"))
        System.out.println(m.getParameterTypes()[0].getSimpleName() + " bridge=" + m.isBridge());
// Name bridge=false
// Object bridge=true     <- generated by the compiler

Raw types and heap pollution

A raw type is a generic type used without its type argument (List instead of List<String>). It exists only for compatibility with pre-Java-5 code. It turns the checks off, and the error then shows up far from the real bug:

List<String> names = new ArrayList<>();
List raw = names;           // raw type: warning only
raw.add(42);                // "unchecked" warning, but compiles -- heap pollution
String first = names.get(0);
// ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String
// (thrown HERE, at the hidden cast, not where 42 was added)

Use List<?> when you truly don't care about the type. Treat "unchecked" warnings as errors. @SafeVarargs is how a generic varargs method promises it doesn't pollute the heap.

19. The Collections Framework

The hierarchy

• List — ordered by index, duplicates allowed.
• Set — no duplicates (decided by equals/hashCode, or by the comparator for TreeSet).
• Queue — hold items for processing (usually FIFO); Deque ("deck") adds both ends, so it works as a stack too.
• Map — key to value pairs, unique keys. Not a Collection because its elements are pairs.
• Also: SortedSet/NavigableSet and SortedMap/NavigableMap add sorted views and floor/ceiling; Java 21 added SequencedCollection/SequencedMap (JEP 431) with getFirst(), getLast(), reversed() for anything with a defined order.

Each implementation, inside

*Unless your comparator explicitly handles null.

Complexity table

Iterating a HashMap visits every bucket, so a map that once held a million entries and is now nearly empty still iterates slowly. LinkedHashMap follows its linked list and costs only O(n).

Order in practice

List<String> in = List.of("banana", "apple", "cherry", "date");
new LinkedHashSet<>(in);     // [banana, apple, cherry, date]  insertion order
new TreeSet<>(in);           // [apple, banana, cherry, date]  sorted
PriorityQueue<Integer> pq = new PriorityQueue<>(List.of(5, 1, 8, 3, 2));
System.out.println(pq);      // [1, 2, 8, 3, 5]  heap layout, not sorted!
pq.poll();                   // 1

// LRU cache in 5 lines: access order + evict eldest
Map<String, Integer> lru = new LinkedHashMap<>(16, 0.75f, true) {
    protected boolean removeEldestEntry(Map.Entry<String, Integer> e) { return size() > 3; }
};
lru.put("a", 1); lru.put("b", 2); lru.put("c", 3);
lru.get("a");                // "a" becomes most recent
lru.put("d", 4);             // evicts "b", the least recently used
System.out.println(lru);     // {c=3, a=1, d=4}

// Java 21 sequenced collections
List<Integer> seq = new ArrayList<>(List.of(1, 2, 3));
seq.getFirst(); seq.getLast(); seq.reversed();   // 1, 3, [3, 2, 1]

How to choose

LinkedList almost never wins: even "insert in the middle" needs an O(n) walk to find the spot, and ArrayList's System.arraycopy shift is very fast in practice. Legacy classes Vector, Stack and Hashtable synchronize every method; use ArrayList, ArrayDeque and HashMap/ConcurrentHashMap instead.

Immutable and unmodifiable collections

String[] arr = {"x", "y", "z"};
List<String> asList = Arrays.asList(arr);
asList.set(0, "X");          // ok -- and it writes through: arr is now [X, y, z]
asList.add("w");             // UnsupportedOperationException (fixed size)
Arrays.asList("a", null);    // [a, null] -- nulls fine
Arrays.asList(new int[]{1, 2, 3}).size();   // 1 !  a List<int[]> with one element

List<String> backing = new ArrayList<>(List.of("x", "y", "z"));
List<String> unmod = Collections.unmodifiableList(backing);
unmod.set(0, "X");           // UnsupportedOperationException
backing.add("w");
System.out.println(unmod);   // [x, y, z, w]  -- a read-only VIEW, sees changes

List<String> copy = List.copyOf(backing);  // real immutable snapshot (Java 10)
List<String> of = List.of("x", "y", "z");  // Java 9
of.set(0, "X");              // UnsupportedOperationException
List.of("a", null);          // NullPointerException
of.contains(null);           // NullPointerException (even asking!)
Set.of("a", "a");            // IllegalArgumentException: duplicate element
Stream.of(1, 2).toList().add(3);   // UnsupportedOperationException (Java 16)

20. How HashMap Works Inside

Step 1: hashing and spreading

// Inside HashMap (Java 8+)
static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
// Bucket index: (n - 1) & hash       where n = table length, always a power of 2

• Why (n - 1) & hash? When n is a power of two, n - 1 is all ones in binary (16 - 1 = 1111), so the AND keeps just the low bits: the same result as hash % n for non-negative numbers, but faster, and never negative even when hashCode() is negative.
• Why spread with h ^ (h >>> 16)? A small table only looks at the lowest few bits. Keys whose hash codes differ only in the high bits would all collide. XOR-ing the top 16 bits into the bottom 16 lets high bits influence the index.

int h = "apple".hashCode();        // 93029210
int spread = h ^ (h >>> 16);       // 93030097
int index = spread & (16 - 1);     // 1

int a = 0x10000, b = 0x20000;      // differ only in high bits
(a & 15) + "," + (b & 15)                          // "0,0"  -- both in bucket 0
(spread(a) & 15) + "," + (spread(b) & 15)          // "1,2"  -- spread apart

Step 2: put and get

That is why hashCode and equals must agree: hashCode picks the bucket, equals picks the entry within it. put returns the previous value (null if new): pm.put("x", 1) gives null, then pm.put("x", 2) gives 1.

Step 3: load factor and resize

The load factor (default 0.75) is how full the table may get. The threshold is capacity × loadFactor. When size goes above it, the table doubles and every entry is moved. 0.75 is a trade-off: lower wastes memory, higher means more collisions.

HashMap<Integer, String> m = new HashMap<>();   // table is still null here
// after 1st put:  capacity=16 threshold=12
// after 12th put: capacity=16 threshold=12
// after 13th put: capacity=32 threshold=24   <- resized

new HashMap<>(100);   // capacity rounds UP to a power of two: 128 (threshold 96)

On a resize from n to 2n, each entry either stays at index i or moves to i + n, decided by the single bit hash & n. Java 8 splits each bucket into a "lo" and "hi" list and keeps the relative order. If you know the size in advance, pre-size: new HashMap<>(expected * 4 / 3 + 1), or since Java 19 HashMap.newHashMap(expected), to avoid repeated resizing.

Step 4: collisions and treeify

A bucket starts as a linked list. When a put makes a bucket reach 9 nodes (it already had 8 = TREEIFY_THRESHOLD), HashMap wants to turn it into a red-black tree so lookups in that bucket become O(log n) instead of O(n). But if the whole table is smaller than 64 (MIN_TREEIFY_CAPACITY), it resizes instead — a small table probably just needs more buckets. A tree shrinks back to a list when a resize split leaves 6 or fewer nodes (UNTREEIFY_THRESHOLD).

// Every key has the same hashCode -> all land in ONE bucket
record BadKey(int id) implements Comparable<BadKey> {
    @Override public int hashCode() { return 42; }
    @Override public int compareTo(BadKey o) { return Integer.compare(id, o.id); }
}

// Table already at 64 (new HashMap<>(64)); bucket type read via reflection:
// nodes=8  bucket=Node       (linked list)
// nodes=9  bucket=TreeNode   <- 9th node triggers treeify

// Default table of 16:
// nodes=8  cap=16 bucket=Node
// nodes=9  cap=32 bucket=Node       <- table too small: resize instead
// nodes=10 cap=64 bucket=Node       <- resize again
// nodes=11 cap=64 bucket=TreeNode   <- now treeify

(The bucket type was read with reflection and --add-opens java.base/java.util=ALL-UNNAMED; do not do this in real code.) Trees order nodes by hash, then by compareTo if the keys are Comparable, so making keys Comparable helps in the worst case. Treeify exists mainly as a defence against hash-flooding attacks, where someone sends many keys with the same hash to make your server do O(n) work per lookup.

The null key

HashMap<String, Integer> nm = new HashMap<>();
nm.put(null, 1); nm.put(null, 2);
nm.get(null);                                    // 2, size 1, stored in bucket 0 (hash(null) = 0)
new Hashtable<String, Integer>().put(null, 1);          // NullPointerException
new ConcurrentHashMap<String, Integer>().put(null, 1);  // NullPointerException

ConcurrentHashMap forbids null because get(k) == null would be ambiguous between threads: "absent" or "mapped to null"? You cannot safely follow up with containsKey when another thread may change the map in between.

Why keys should be immutable

final class MutableKey {
    int id;
    MutableKey(int id) { this.id = id; }
    @Override public boolean equals(Object o) { return o instanceof MutableKey m && m.id == id; }
    @Override public int hashCode() { return Integer.hashCode(id); }
}
Map<MutableKey, String> mm = new HashMap<>();
MutableKey key = new MutableKey(1);
mm.put(key, "data");
key.id = 2;                           // hash changes, but the entry stays in the OLD bucket
mm.get(key);                          // null  -- looks in the bucket for hash(2)
mm.get(new MutableKey(1));            // null  -- right bucket, but equals fails (id is now 2)
mm.size();                            // 1     -- the entry is stuck: a memory leak
mm.containsValue("data");             // true

Use immutable keys: String, Integer, records with immutable fields, enums. String also caches its hash code, which makes it a fast key.

Java 7 vs Java 8

Not thread-safe

Two threads calling put at the same time can overwrite each other's entries, lose updates to size, or corrupt a bucket during resize. Options: ConcurrentHashMap (the right answer: CAS on empty buckets plus a lock on one bucket's head node, lock-free reads) or Collections.synchronizedMap (one lock for the whole map, slower). Hashtable is legacy.

21. Comparable, Comparator & Sorting

Both in code

record Employee(String name, String dept, int salary) implements Comparable<Employee> {
    @Override public int compareTo(Employee o) { return name.compareTo(o.name); }  // natural: by name
}
List<Employee> staff = new ArrayList<>(List.of(
    new Employee("Maya", "Eng", 120), new Employee("Arun", "Sales", 90),
    new Employee("Zoe", "Eng", 150),  new Employee("Liam", "Sales", 90),
    new Employee("Chen", "Eng", 120)));

Collections.sort(staff);   // natural order -> [Arun, Chen, Liam, Maya, Zoe]

// Comparator chain: dept A-Z, then salary high-to-low, then name A-Z
staff.sort(Comparator.comparing(Employee::dept)
        .thenComparing(Employee::salary, Comparator.reverseOrder())
        .thenComparing(Employee::name));
// Eng 150 Zoe
// Eng 120 Chen
// Eng 120 Maya
// Sales 90 Arun
// Sales 90 Liam

The Comparator toolkit (Java 8+)

List<String> withNull = new ArrayList<>(Arrays.asList("pear", null, "apple"));
withNull.sort(Comparator.nullsFirst(Comparator.naturalOrder()));
// [null, apple, pear]
withNull.sort(Comparator.nullsLast(Comparator.<String>naturalOrder().reversed()));
// [pear, apple, null]

TreeMap<String, Integer> ci = new TreeMap<>(String.CASE_INSENSITIVE_ORDER);
ci.put("Apple", 1); ci.put("apple", 2);
// {Apple=2}  -- the comparator says they're equal, so it's the SAME key

Trap: comparing(A).thenComparing(B).reversed() reverses both A and B. To reverse only one key, pass Comparator.reverseOrder() as its second argument, as in the salary example above.

Sorting stability

A sort is stable if elements that compare equal keep their original relative order. List.sort, Collections.sort, Arrays.sort(Object[]) and Stream.sorted use TimSort, which is stable and O(n log n) (close to O(n) on nearly sorted data). Arrays.sort(int[]) uses dual-pivot quicksort, not stable — which does not matter because equal primitives are indistinguishable.

// Sort by name first, then by salary: equal salaries stay in name order
staff.sort(Comparator.naturalOrder());
staff.sort(Comparator.comparingInt(Employee::salary));
// [90:Arun, 90:Liam, 120:Chen, 120:Maya, 150:Zoe]

The a - b overflow bug

Comparator<Integer> bad  = (x, y) -> x - y;          // looks clever, is broken
Comparator<Integer> good = Integer::compare;

int big = 2_000_000_000, neg = -2_000_000_000;
bad.compare(neg, big);     // 294967296   positive?! -4e9 overflowed and wrapped
good.compare(neg, big);    // -1

List<Integer> nums = new ArrayList<>(List.of(big, neg, 0));
nums.sort(bad);            // [2000000000, -2000000000, 0]   wrong
nums.sort(good);           // [-2000000000, 0, 2000000000]   right

Use Integer.compare, Long.compare, Double.compare or Comparator.comparingInt. Subtraction is only safe when you know both values are small and non-negative — and it's not worth the risk.

The comparator contract

• Antisymmetric: sign of compare(a, b) = minus sign of compare(b, a).
• Transitive: if a > b and b > c, then a > c.
• Consistent: if compare(a, b) == 0, then a and b compare the same against everything else.
• Recommended: consistent with equals (compare == 0 exactly when equals is true). Sorted collections use only the comparator, so if they disagree, sets behave oddly:

new HashSet<>(List.of(new BigDecimal("1.0"), new BigDecimal("1.00"))).size();   // 2 (equals: scale differs)
new TreeSet<>(List.of(new BigDecimal("1.0"), new BigDecimal("1.00"))).size();   // 1 (compareTo: same value)

Breaking the contract (for example a comparator that returns random results or mixes up signs) can make TimSort throw IllegalArgumentException: Comparison method violates its general contract! — but only for some inputs, so it shows up as a rare production bug.

22. Iterators, Fail-fast & Fail-safe

Iterator and ListIterator

// for (String s : list) { ... }  is compiled to roughly:
Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    ...
}

// ListIterator: both directions, index, set and add while walking
List<String> words = new ArrayList<>(List.of("a", "b", "c"));
ListIterator<String> li = words.listIterator();
while (li.hasNext()) {
    int idx = li.nextIndex();
    String w = li.next();
    li.set(w.toUpperCase());         // replace the element just returned
    if (idx == 0) li.add("a2");      // insert after it; the cursor skips past it
}
// words = [A, a2, B, C]
StringBuilder back = new StringBuilder();
while (li.hasPrevious()) back.append(li.previous());
// back = "CBa2A"

ConcurrentModificationException and modCount

Each ArrayList/HashMap keeps a counter, modCount, that goes up on every structural change (add, remove, clear, resize — but not set). An iterator copies it into expectedModCount when created. Every next() compares the two; if they differ, it throws.

List<Integer> list = new ArrayList<>(List.of(1, 2, 3, 4, 5));
for (Integer x : list) if (x == 2) list.remove(x);
// ConcurrentModificationException  (list is now [1, 3, 4, 5])

// The famous quirk: removing the SECOND-TO-LAST element does not throw
List<Integer> q = new ArrayList<>(List.of(1, 2, 3));
for (Integer x : q) if (x == 2) q.remove(x);
// no exception, q = [1, 3] -- but 3 was never visited!
// hasNext() is just "cursor != size": cursor=2, size=2, so the loop ends before next() can check.

Map<String, Integer> hm = new HashMap<>(Map.of("a", 1, "b", 2));
for (String k : hm.keySet()) hm.put(k + "x", 0);   // ConcurrentModificationException

The exception has "Concurrent" in its name but happens here in a single thread. Fail-fast is also only "best effort": with real multi-threading, it is not guaranteed to fire, so never rely on it for correctness — it exists to reveal bugs.

The right ways to remove while iterating

// 1. Iterator.remove()
Iterator<Integer> it = r.iterator();
while (it.hasNext()) if (it.next() % 2 == 0) it.remove();
// [1, 2, 3, 4, 5] -> [1, 3, 5]

// 2. removeIf (Java 8) -- shortest, and O(n) for ArrayList (one compaction pass)
r2.removeIf(x -> x % 2 == 0);                 // [1, 3, 5]

// 3. On maps, go through a view
scores.values().removeIf(v -> v < 50);        // {a=10, b=55, c=70} -> {b=55, c=70}
scores.entrySet().removeIf(e -> e.getKey().startsWith("tmp"));

// 4. Build a new collection (streams / filter) instead of mutating
List<Integer> odds = r.stream().filter(x -> x % 2 != 0).toList();

// 5. Index loop going BACKWARDS (removing forwards skips elements)
for (int i = list.size() - 1; i >= 0; i--) if (list.get(i) % 2 == 0) list.remove(i);

Removing with it.remove() in a loop over an ArrayList is O(n) per removal (each shifts the tail), so O(n²) overall; removeIf does it in one pass.

Fail-safe: CopyOnWriteArrayList and ConcurrentHashMap

// CopyOnWriteArrayList: every write copies the whole array; iterators use a SNAPSHOT
List<Integer> cow = new CopyOnWriteArrayList<>(List.of(1, 2, 3));
for (Integer x : cow) { if (x == 1) cow.add(99); System.out.print(x + " "); }
// prints: 1 2 3        (the snapshot doesn't see 99)
// cow afterwards: [1, 2, 3, 99]
cow.iterator().remove();   // UnsupportedOperationException -- snapshot iterators are read-only

// ConcurrentHashMap: weakly consistent iterators -- never throw CME
Map<String, Integer> chm = new ConcurrentHashMap<>(Map.of("a", 1, "b", 2, "c", 3));
for (String k : chm.keySet()) if (k.equals("a")) chm.remove("b");
// no exception; map is now {a=1, c=3}

23. Optional

Creating one

Optional.of("x");            // Optional[x]      value must be non-null
Optional.of(null);           // NullPointerException
Optional.ofNullable(null);   // Optional.empty   use when the value might be null
Optional.empty();            // Optional.empty

static Optional<User> findById(int id) {
    return Optional.ofNullable(db.get(id));   // Map.get returns null when absent
}

Transforming: map, flatMap, filter

record Address(String city) {}
record User(String name, Address address, String email) {
    Optional<String> emailOpt() { return Optional.ofNullable(email); }
}
// db: 1 -> Asha (Pune, asha@x.io),  2 -> Ben (no address, no email)

findById(1).map(User::address).map(Address::city).orElse("unknown");   // "Pune"
findById(2).map(User::address).map(Address::city).orElse("unknown");   // "unknown"
findById(9).map(User::address).map(Address::city).orElse("unknown");   // "unknown"

// map vs flatMap: use flatMap when the function ALREADY returns an Optional
findById(1).map(User::emailOpt);       // Optional[Optional[asha@x.io]]  -- nested
findById(1).flatMap(User::emailOpt);   // Optional[asha@x.io]            -- flat

findById(1).filter(u -> u.name().startsWith("A"))
           .ifPresentOrElse(u -> System.out.println("hello " + u.name()),
                            () -> System.out.println("nobody"));        // hello Asha

Getting the value out

orElse vs orElseGet — the side-effect trap

The argument to orElse is an ordinary expression, so Java evaluates it before calling the method — even when the Optional has a value and the result is thrown away. orElseGet takes a Supplier and calls it only when empty.

static int calls = 0;
static String expensiveDefault() {
    calls++;
    System.out.println("  expensiveDefault() called");
    return "default";
}

System.out.println("orElse on present value:");
String v1 = Optional.of("real").orElse(expensiveDefault());
System.out.println("  result=" + v1);
System.out.println("orElseGet on present value:");
String v2 = Optional.of("real").orElseGet(OptDemo::expensiveDefault);
System.out.println("  result=" + v2);
System.out.println("calls=" + calls);

// Output:
// orElse on present value:
//   expensiveDefault() called        <- ran for nothing
//   result=real
// orElseGet on present value:
//   result=real                      <- supplier never called
// calls=1

Rule: orElse for constants (orElse("unknown"), orElse(0)); orElseGet when the default costs something or has side effects (database call, new object, logging). A real bug: findUser(id).orElse(createUser(id)) creates a user in the database every time.

orElseThrow and chaining alternatives

User u = findById(9).orElseThrow(() -> new NoSuchElementException("user 9 not found"));
// NoSuchElementException: user 9 not found

findById(9).orElseThrow();   // NoSuchElementException: No value present
findById(9).get();           // NoSuchElementException: No value present

findById(9).or(() -> findById(2)).map(User::name).orElse("-");   // "Ben"

// Flatten a list of Optionals: keep only the present ones
List.of(1, 2, 9).stream()
    .map(OptDemo::findById)
    .flatMap(Optional::stream)                 // drops the empty ones
    .flatMap(u -> u.emailOpt().stream())
    .toList();                                 // [asha@x.io]

Anti-patterns

OptionalInt max = IntStream.of().max();   // OptionalInt.empty
max.orElse(-1);                           // -1

24. Lambdas & Functional Interfaces

Syntax, from long to short

@FunctionalInterface
interface Calculator { int apply(int a, int b); }   // one abstract method

// Before Java 8: an anonymous class
Calculator addOld = new Calculator() {
    @Override public int apply(int a, int b) { return a + b; }
};

// Lambda forms
Calculator add = (a, b) -> a + b;                    // types inferred, expression body
Calculator mul = (int a, int b) -> { return a * b; }; // explicit types, block body needs return
Runnable hello = () -> System.out.println("hi");     // no parameters: empty ()
Function<String, Integer> len = s -> s.length();     // one parameter: () optional
BiFunction<Integer, Integer, Integer> sum = (var x, var y) -> x + y;  // var allowed (Java 11)

add.apply(2, 3);   // 5
mul.apply(2, 3);   // 6

The compiler works out the lambda's type from the target type — the interface it is assigned or passed to. The same lambda text () -> 42 can be a Supplier<Integer> or a Callable<Integer> depending on where it lands. A lambda on its own, with no target, does not compile (var f = x -> x; is an error).

@FunctionalInterface

The annotation is optional, but it makes the compiler check that the interface really has exactly one abstract method. If someone later adds a second abstract method, the build fails instead of every lambda breaking silently. default and static methods do not count, and neither do methods that match Object's public methods (that is why Comparator can declare equals and still be functional).

The built-in functional interfaces (java.util.function)

Function<String, Integer> len    = s -> s.length();
Supplier<List<String>> newList   = ArrayList::new;
Consumer<String> printer         = s -> System.out.println("> " + s);
Predicate<String> isEmpty        = String::isEmpty;
UnaryOperator<String> upper      = String::toUpperCase;
BinaryOperator<Integer> max      = Math::max;

len.apply("java");      // 4
newList.get().size();   // 0
printer.accept("hi");   // prints "> hi"
isEmpty.test("");       // true
upper.apply("abc");     // "ABC"
max.apply(3, 9);        // 9

Primitive specialisations — avoid boxing

Generics only work with objects, so Function<Integer, Integer> boxes every int into an Integer. For hot code Java offers primitive versions that take and return real int/long/double:

IntPredicate even      = n -> n % 2 == 0;     // even.test(4)          -> true
IntUnaryOperator sq    = n -> n * n;          // sq.applyAsInt(7)      -> 49
ToIntFunction<String> l = String::length;     // l.applyAsInt("abc")   -> 3
IntBinaryOperator plus = Integer::sum;        // plus.applyAsInt(2, 3) -> 5

Note the method names change (applyAsInt, test, getAsInt) so the compiler never has to box.

Composing functions

Default methods on these interfaces let you glue small functions into bigger ones without writing a new lambda.

Function<Integer, Integer> plus2  = x -> x + 2;
Function<Integer, Integer> times3 = x -> x * 3;
plus2.andThen(times3).apply(1);   // 9
plus2.compose(times3).apply(1);   // 5
Function.<Integer>identity().apply(42);   // 42 -- returns its input

Predicate<String> longWord = s -> s.length() > 3;
Predicate<String> startsA  = s -> s.startsWith("a");
longWord.and(startsA).test("apple");           // true  (both)
longWord.or(startsA).test("an");               // true  (either)
longWord.negate().test("apple");               // false
Predicate.not(String::isBlank).test(" ");      // false  (Java 11; handy in filter)

Consumer<List<String>> addA = l -> l.add("a");
List<String> list = new ArrayList<>();
addA.andThen(l -> l.add("b")).accept(list);    // list is [a, b]

and / or short-circuit exactly like && / ||: the second predicate is not called if the first already decides the answer.

Capturing variables: "effectively final"

A lambda can read local variables from the method around it, but only if they are final or effectively final — assigned once and never changed afterwards.

int base = 10;
Function<Integer, Integer> addBase = x -> x + base;   // OK: base never changes
addBase.apply(5);                                     // 15

int count = 0;
List.of("a", "b").forEach(s -> count++);
// error: local variables referenced from a lambda expression
//        must be final or effectively final

Why the rule? Local variables live on the thread's stack and vanish when the method returns, but the lambda may run later or on another thread. So Java copies the value into the lambda. If the variable could still change, the copy and the original would disagree — the rule removes that confusion (and data races on locals). Fields and array elements are not copied (the lambda holds a reference to the object), so they can be changed:

int[] counter = {0};                                 // the array reference is effectively final
List.of("a", "b", "c").forEach(s -> counter[0]++);   // compiles; counter[0] == 3
// Works, but it is a code smell and NOT thread-safe. Prefer stream.count() or an AtomicInteger.

this: lambda vs anonymous class

public class Demo {
    void show() {
        Runnable lambda = () -> System.out.println(this.getClass().getSimpleName());
        Runnable anon = new Runnable() {
            public void run() { System.out.println(this.getClass().getName()); }
        };
        lambda.run();   // Demo      -- 'this' is the enclosing object
        anon.run();     // Demo$1    -- 'this' is the anonymous object itself
    }
}

25. The Streams API

Building a pipeline

record Emp(String name, String dept, int salary) {}

List<String> highPaidEng = emps.stream()                 // source
    .filter(e -> e.dept().equals("Eng"))                  // intermediate
    .filter(e -> e.salary() >= 100)
    .map(Emp::name)                                       // Emp -> String
    .sorted()                                             // intermediate, stateful
    .toList();                                            // terminal (Java 16)

// Other sources
Stream.of("a", "b");                  Arrays.stream(intArray);
IntStream.range(0, 10);               // 0..9
Stream.iterate(1, n -> n * 2);        // infinite: 1, 2, 4, 8, ...
Stream.generate(Math::random);        // infinite
Files.lines(path);                    // lines of a file (close it: try-with-resources)
"text".chars();                       // IntStream of chars

Laziness — proved with peek

peek runs an action on each element as it passes. It lets us see when work really happens:

Stream<String> s = Stream.of("a", "bb", "ccc")
    .peek(x -> System.out.println("peek " + x));
System.out.println("pipeline built, nothing printed yet");
System.out.println("count of long = " + s.filter(x -> x.length() > 1).count());

pipeline built, nothing printed yet
peek a
peek bb
peek ccc
count of long = 2

Now watch how elements move. Streams process vertically — one element goes through every step before the next one starts — and findFirst stops as soon as it has an answer:

Optional<Integer> first = Stream.of(1, 2, 3, 4, 5, 6)
    .peek(n -> System.out.println("saw " + n))
    .filter(n -> n % 2 == 0)
    .map(n -> n * 10)
    .findFirst();
System.out.println("result " + first.get());

// Output:
// saw 1
// saw 2
// result 20        -- elements 3..6 were never touched

Stateless vs stateful operations

Stream.of(3, 1, 2)
    .peek(n -> System.out.println("before sort " + n))
    .sorted()
    .forEach(n -> System.out.println("after sort " + n));
// before sort 3, before sort 1, before sort 2, after sort 1, after sort 2, after sort 3

Short-circuiting

A short-circuiting operation can finish without looking at every element — which is what makes infinite streams usable.

Stream.iterate(1, n -> n * 2).limit(5).toList();            // [1, 2, 4, 8, 16]
IntStream.iterate(1, n -> n + 1).anyMatch(n -> n * n > 50);  // true (stops at 8)
Stream.iterate(1, n -> n < 20, n -> n * 3).toList();        // [1, 3, 9]   (Java 9)
Stream.of(1, 2, 3, 10, 4).takeWhile(n -> n < 5).toList();   // [1, 2, 3]   (Java 9)
Stream.of(1, 2, 3, 10, 4).dropWhile(n -> n < 5).toList();   // [10, 4]
// Others: findFirst, findAny, allMatch, noneMatch

takeWhile is not filter: it stops at the first failure (the 4 after 10 is dropped).

map vs flatMap

map turns each element into exactly one element. flatMap turns each element into a stream of zero or more elements and flattens them into one stream.

List<List<Integer>> nested = List.of(List.of(1, 2), List.of(3), List.of());
nested.stream().map(List::size).toList();          // [2, 1, 0]
nested.stream().flatMap(List::stream).toList();    // [1, 2, 3]

Stream.of("hi there", "java")
    .flatMap(line -> Arrays.stream(line.split(" ")))
    .toList();                                     // [hi, there, java]
// Also: mapMulti (Java 16) -- a push-style flatMap that avoids creating small streams

reduce — fold everything into one value

int sum = Stream.of(1, 2, 3, 4).reduce(0, Integer::sum);      // 10   identity + accumulator
Optional<Integer> max = Stream.of(1, 7, 3).reduce(Integer::max); // Optional[7]  no identity
Stream.<Integer>empty().reduce(Integer::sum);                  // Optional.empty

// Three-arg form: result type differs from element type
int totalLen = Stream.of("ab", "cde")
    .reduce(0, (acc, w) -> acc + w.length(), Integer::sum);    // 5  (combiner used in parallel)

Rules for correct (and parallel-safe) reduce: the identity must really be neutral (0 for sum, 1 for product), and the operation must be associative ((a+b)+c == a+(b+c)). Subtraction is not, so a parallel reduce with (a, b) -> a - b gives wrong answers. For building collections, use collect, not reduce.

A stream can be used only once

Stream<Integer> once = Stream.of(1, 2, 3);
once.count();
once.count();   // IllegalStateException: stream has already been operated upon or closed

// Need it twice? Keep a Supplier and make a fresh stream each time
Supplier<Stream<Integer>> nums = () -> Stream.of(1, 2, 3);
nums.get().count(); nums.get().count();   // fine

Primitive streams and the cost of boxing

Stream<Integer> holds Integer objects; IntStream, LongStream and DoubleStream hold raw numbers and add math methods (sum, average, summaryStatistics, range).

IntStream.rangeClosed(1, 5).summaryStatistics();
// IntSummaryStatistics{count=5, sum=15, min=1, average=3.000000, max=5}
IntStream.of(3, 5).average().getAsDouble();           // 4.0
Stream.of("a", "bb").mapToInt(String::length).sum();  // 3   object -> primitive
IntStream.range(0, 3).boxed().toList();               // [0, 1, 2]  primitive -> object

On a 5-million-element List<Integer>, reduce(0, Integer::sum) (unbox, add, re-box every step) ran several times slower than mapToInt(Integer::intValue).sum() in our test, and a plain for loop over an int range was faster still. Exact numbers vary by machine and JIT warm-up, but the order holds: convert to a primitive stream as early as you can.

Parallel streams — and when they hurt

.parallel() (or collection.parallelStream()) splits the source into chunks and runs them on the shared ForkJoinPool.commonPool() (about one thread per CPU core), then combines results.

// BROKEN: many threads calling ArrayList.add at once
List<Integer> unsafe = new ArrayList<>();
IntStream.range(0, 10_000).parallel().forEach(unsafe::add);
// In our run, 15 of 20 trials lost elements or threw ArrayIndexOutOfBoundsException

// CORRECT: let the stream build the result
List<Integer> safe = IntStream.range(0, 10_000).parallel().boxed().toList();  // always 10000

IntStream.range(0, 8).parallel().forEach(i -> System.out.print(i + " "));
// e.g. 2 5 3 4 7 6 0 1   -- order is NOT kept (differs every run)
IntStream.range(0, 8).parallel().forEachOrdered(i -> System.out.print(i + " "));
// 0 1 2 3 4 5 6 7

Parallel hurts when:

• The data is small (thousands of elements) — splitting and joining cost more than the work.
• The source splits badly: LinkedList, Stream.iterate, I/O lines. ArrayList, arrays and IntStream.range split well.
• The steps block (HTTP, DB calls) — they tie up the common pool that the whole JVM shares.
• The pipeline has order-dependent ops (limit, findFirst, sorted) on an ordered stream, or shared mutable state / locks.
• Boxing dominates the cost anyway.

It helps for large, CPU-heavy, independent work on an easily split source. Always measure (JMH) before and after.

Stream vs loop

26. Collectors & Method References

All examples below use this data:

record Emp(String name, String dept, int salary) {}
List<Emp> emps = List.of(
    new Emp("Asha", "Eng", 120), new Emp("Ben", "Eng", 100),
    new Emp("Cara", "Sales", 80), new Emp("Dev", "Sales", 90),
    new Emp("Eli", "HR", 70));

toList: three versions, three behaviours

List<String> a = emps.stream().map(Emp::name).collect(Collectors.toList());
a.add("X");                  // works -- in practice an ArrayList (spec does not promise the type)

List<String> b = emps.stream().map(Emp::name).toList();         // Java 16
b.add("X");                  // UnsupportedOperationException -- unmodifiable

List<String> c = emps.stream().map(Emp::name).collect(Collectors.toUnmodifiableList()); // Java 10

Stream.of("a", null).toList();                                    // [a, null]  allows null
Stream.of("a", null).collect(Collectors.toUnmodifiableList());    // NullPointerException

Swapping collect(Collectors.toList()) for .toList() during a refactor is a classic bug if some later code calls add on the result.

toMap and the duplicate-key trap

Map<String, Integer> byName = emps.stream()
    .collect(Collectors.toMap(Emp::name, Emp::salary));   // names are unique: fine

emps.stream().collect(Collectors.toMap(Emp::dept, Emp::name));
// IllegalStateException: Duplicate key Eng (attempted merging values Asha and Ben)

// Fix: a merge function says what to do when two values share a key
Map<String, Integer> deptTotal = emps.stream()
    .collect(Collectors.toMap(Emp::dept, Emp::salary, Integer::sum, TreeMap::new));
// {Eng=220, HR=70, Sales=170}   4th arg picks the map type (sorted here)

Other merge choices: (a, b) -> a keep first, (a, b) -> b keep last. Also, toMap throws NullPointerException if a value is null (it uses Map.merge inside).

groupingBy — the SQL GROUP BY of Java

Map<String, List<Emp>> byDept = emps.stream().collect(Collectors.groupingBy(Emp::dept));
// HashMap: key order not defined

Map<String, Long> counts = emps.stream()
    .collect(Collectors.groupingBy(Emp::dept, TreeMap::new, Collectors.counting()));
// {Eng=2, HR=1, Sales=2}

Map<String, List<String>> names = emps.stream()
    .collect(Collectors.groupingBy(Emp::dept, TreeMap::new,
             Collectors.mapping(Emp::name, Collectors.toList())));
// {Eng=[Asha, Ben], HR=[Eli], Sales=[Cara, Dev]}

Map<String, Integer> sums = emps.stream()
    .collect(Collectors.groupingBy(Emp::dept, TreeMap::new, Collectors.summingInt(Emp::salary)));
// {Eng=220, HR=70, Sales=170}

Map<String, Double> avg = emps.stream()
    .collect(Collectors.groupingBy(Emp::dept, TreeMap::new, Collectors.averagingInt(Emp::salary)));
// {Eng=110.0, HR=70.0, Sales=85.0}

Map<String, Optional<Emp>> top = emps.stream()
    .collect(Collectors.groupingBy(Emp::dept,
             Collectors.maxBy(Comparator.comparingInt(Emp::salary))));
// Eng -> Asha, HR -> Eli, Sales -> Dev

// Word frequency -- a very common interview task
Map<String, Long> freq = Arrays.stream("the cat and the hat and the bat".split(" "))
    .collect(Collectors.groupingBy(Function.identity(), TreeMap::new, Collectors.counting()));
// {and=2, bat=1, cat=1, hat=1, the=3}

Useful downstream collectors: counting, summingInt/Long/Double, averagingInt, minBy/maxBy, mapping, filtering and flatMapping (Java 9), toSet, joining, collectingAndThen (e.g. unwrap the Optional from maxBy). Use groupingByConcurrent for parallel streams.

partitioningBy, joining, teeing

// partitioningBy: exactly two groups, keyed true / false
Map<Boolean, List<String>> part = emps.stream()
    .collect(Collectors.partitioningBy(e -> e.salary() >= 100,
             Collectors.mapping(Emp::name, Collectors.toList())));
// {false=[Cara, Dev, Eli], true=[Asha, Ben]}
Stream.<Emp>empty().collect(Collectors.partitioningBy(e -> true));
// {false=[], true=[]}   both keys always present (groupingBy would give {})

// joining: strings only, with optional separator, prefix, suffix
emps.stream().map(Emp::name).collect(Collectors.joining(", ", "[", "]"));
// [Asha, Ben, Cara, Dev, Eli]

// teeing (Java 12): feed every element to TWO collectors, then merge the results
double avgAll = emps.stream().collect(Collectors.teeing(
    Collectors.summingInt(Emp::salary),
    Collectors.counting(),
    (sum, n) -> (double) sum / n));                 // 92.0

record MinMax(int min, int max) {}
MinMax mm = emps.stream().map(Emp::salary).collect(Collectors.teeing(
    Collectors.minBy(Integer::compare), Collectors.maxBy(Integer::compare),
    (mn, mx) -> new MinMax(mn.get(), mx.get())));   // MinMax[min=70, max=120]

Method references — four kinds

Function<String, Integer> parse = Integer::parseInt;            // static
parse.apply("42") + 1;                                          // 43

String prefix = "Hello, ";
Function<String, String> greet = prefix::concat;               // bound: receiver fixed now
greet.apply("Ana");                                             // "Hello, Ana"

Function<String, String> up = String::toUpperCase;             // unbound: receiver is the 1st arg
BiFunction<String, String, Boolean> eq = String::equalsIgnoreCase;
eq.apply("Java", "JAVA");                                       // true  ("Java".equalsIgnoreCase("JAVA"))

Supplier<ArrayList<String>> mk = ArrayList::new;               // constructor
Function<Integer, int[]> arr = int[]::new;                      // arr.apply(3).length == 3
String[] out = Stream.of("x", "y").toArray(String[]::new);      // [x, y]

The trick for unbound references: the first parameter of the functional interface becomes the object the method is called on; the rest become its arguments. A bound reference evaluates its receiver once, when the reference is created (and throws NPE right then if it is null).

27. Date & Time API

Why java.util.Date and Calendar are bad

Date d = new Date(2024, 1, 15);           // deprecated constructor
d.getYear() + 1900;   // 3924  -- year is an offset from 1900
d.getMonth();         // 1     -- months start at 0, so 1 means FEBRUARY

Calendar cal = Calendar.getInstance();
cal.set(2024, 1, 15);                     // also February: 0-based months again

Date shared = new Date(0);
Date alias = shared;
alias.setTime(86_400_000L);               // mutable: changes 'shared' too

• Mutable — a Date passed to another method or stored in a field can be changed behind your back; not thread-safe.
• Bad naming — Date is really an instant (milliseconds since 1970), not a date; its toString uses the JVM's default zone.
• 0-based months, 1900-based years.
• SimpleDateFormat is not thread-safe — sharing one as a static field corrupts results under load.
• No separate types for "date only", "time only", "duration".

Convert at the edges when an old API forces you: date.toInstant() and Date.from(instant).

The main classes

Working with dates — all immutable

LocalDate date = LocalDate.of(2024, 2, 28);    // months are 1-based here
date.plusDays(1);                     // 2024-02-29  (2024 is a leap year)
date.plusDays(2);                     // 2024-03-01
LocalDate.of(2024, 1, 31).plusMonths(1);        // 2024-02-29  clamped to last valid day
date.with(TemporalAdjusters.lastDayOfMonth());  // 2024-02-29
date.getDayOfWeek();                  // WEDNESDAY

LocalDate x = LocalDate.of(2024, 1, 1);
x.plusDays(5);                        // result thrown away!
System.out.println(x);                // 2024-01-01 -- unchanged; write x = x.plusDays(5)

Period age = Period.between(LocalDate.of(1990, 5, 20), LocalDate.of(2024, 3, 10));
// P33Y9M19D  -> 33 years, 9 months, 19 days
Duration shift = Duration.between(LocalTime.of(9, 15), LocalTime.of(17, 45));
// PT8H30M, shift.toMinutes() == 510
ChronoUnit.DAYS.between(LocalDate.of(2024, 1, 1), LocalDate.of(2024, 12, 31));  // 365

Instant.ofEpochSecond(0);                        // 1970-01-01T00:00:00Z
Instant.ofEpochMilli(1_700_000_000_000L);        // 2023-11-14T22:13:20Z

Formatting and parsing

DateTimeFormatter f = DateTimeFormatter.ofPattern("dd/MM/yyyy HH:mm");   // immutable, thread-safe
LocalDateTime.of(2024, 3, 10, 14, 30).format(f);     // "10/03/2024 14:30"
LocalDateTime.parse("25/12/2024 08:05", f);          // 2024-12-25T08:05
LocalDate.parse("2024-07-04");                       // ISO format needs no formatter
DateTimeFormatter.ofPattern("EEE, d MMM yyyy", Locale.US).format(date);   // "Wed, 28 Feb 2024"

LocalDate.parse("2024-13-01");
// DateTimeParseException: ... Invalid value for MonthOfYear (valid values 1 - 12): 13

Time zones and DST pitfalls

A zone (ZoneId.of("America/New_York")) is a set of rules that says what offset from UTC applies on each date — and those offsets change with daylight saving time (DST). An offset (+05:00) is just a fixed number.

ZoneId ny = ZoneId.of("America/New_York");
// US clocks jump from 02:00 to 03:00 on 2024-03-10
ZonedDateTime t = ZonedDateTime.of(2024, 3, 10, 1, 30, 0, 0, ny);
// 2024-03-10T01:30-05:00[America/New_York]
t.plusHours(1);   // 2024-03-10T03:30-04:00  -- exactly 1 hour of real time later
t.plusDays(1);    // 2024-03-11T01:30-04:00  -- same wall-clock time next day (only 23 real hours)

ZonedDateTime.of(2024, 3, 10, 2, 30, 0, 0, ny);
// 2024-03-10T03:30-04:00  -- 02:30 does not exist (the "gap"); shifted forward

// Clocks fall back 02:00 -> 01:00 on 2024-11-03: 01:30 happens TWICE (the "overlap")
ZonedDateTime o = ZonedDateTime.of(2024, 11, 3, 1, 30, 0, 0, ny);
o.withEarlierOffsetAtOverlap();   // 2024-11-03T01:30-04:00
o.withLaterOffsetAtOverlap();     // 2024-11-03T01:30-05:00

ZonedDateTime noon = ZonedDateTime.of(2024, 3, 9, 12, 0, 0, 0, ny);
Duration.between(noon, noon.plusDays(1)).toHours();   // 23, not 24

t.withZoneSameInstant(ZoneId.of("Asia/Tokyo"));  // 2024-03-10T15:30+09:00  same moment
t.withZoneSameLocal(ZoneId.of("Asia/Tokyo"));    // 2024-03-10T01:30+09:00  same clock, different moment

• Store and compute in UTC (Instant / OffsetDateTime in UTC); convert to a user's zone only for display.
• Never use LocalDateTime for events — it has no zone, so "2024-11-03T01:30" is ambiguous and cannot be ordered across users.
• Use region IDs (Europe/Paris), not abbreviations like "EST"/"PST" (ambiguous, ignore DST) or fixed offsets for people who live somewhere.
• Don't rely on the server's default zone (ZoneId.systemDefault()) — pass zones explicitly.
• Inject a Clock (LocalDate.now(clock)) so tests can freeze time with Clock.fixed(...).
• Zone rules change by law; the JDK ships a tz database that needs updating (JDK updates or the TZUpdater tool).

28. Threads & Their Lifecycle

Process vs thread

A classic Java Thread is a platform thread: a thin wrapper around one OS thread. Java 21 also adds cheap virtual threads (section 34).

Three ways to create work for a thread

// 1. Extend Thread (least flexible: uses up your one superclass)
Thread t1 = new Thread() {
    @Override public void run() { System.out.println("subclass: " + Thread.currentThread().getName()); }
};

// 2. Pass a Runnable (preferred: task separated from the thread that runs it)
Thread t2 = new Thread(() -> System.out.println("runnable: " + Thread.currentThread().getName()),
                       "worker-2");
t1.start(); t1.join();     // subclass: Thread-0
t2.start(); t2.join();     // runnable: worker-2

// 3. Callable: returns a value and may throw checked exceptions
Callable<Integer> task = () -> 6 * 7;
FutureTask<Integer> ft = new FutureTask<>(task);   // a Runnable that captures the result
new Thread(ft).start();
ft.get();                                           // 42 (blocks until done)

// Java 21 builder API
Thread b = Thread.ofPlatform().name("built").start(() -> System.out.println("builder"));
b.join();

In real code you rarely call new Thread; you submit tasks to an ExecutorService (section 31).

Thread lifecycle

Each state, seen by calling getState() in a real run:

Thread sleeper = new Thread(() -> { try { Thread.sleep(500); } catch (InterruptedException e) {} });
sleeper.getState();   // NEW
sleeper.start();
sleeper.getState();   // RUNNABLE
Thread.sleep(100);
sleeper.getState();   // TIMED_WAITING   (inside sleep)
sleeper.join();
sleeper.getState();   // TERMINATED

// thread calling lock.wait()                    -> WAITING
// thread trying to enter synchronized(lock)
//   while main holds that lock                  -> BLOCKED

BLOCKED vs WAITING: BLOCKED means "I want to enter a synchronized block but another thread holds the lock" — it gets out automatically when the lock frees. WAITING means "I chose to wait until someone signals me" (wait, join, LockSupport.park). A thread waiting on a ReentrantLock shows as WAITING, not BLOCKED, because those locks use park.

start() vs run()

Thread r = new Thread(() -> System.out.println("run() executes on: " + Thread.currentThread().getName()),
                      "worker");
r.run();     // run() executes on: main     -- just a normal method call, no new thread!
r.start();   // run() executes on: worker   -- new thread, which then calls run()
r.join();
r.start();   // IllegalThreadStateException -- a thread can be started only once

join, sleep, wait

• t.join() — the calling thread waits until t finishes. join(ms) waits at most that long. It also guarantees you see everything t wrote (happens-before, section 29).
• Thread.sleep(ms) — pause the current thread. It is static: t.sleep(1000) still sleeps the caller, not t.
• obj.wait() — release obj's lock and wait for a notify.

Interruption — the polite way to stop a thread

Java has no safe way to kill a thread (Thread.stop was deprecated long ago and throws UnsupportedOperationException since Java 20, because it could leave objects half-updated). Instead you ask it to stop with t.interrupt(), which sets a flag. The thread must cooperate:

// Case 1: the thread is blocked in sleep / wait / join -> it gets InterruptedException
Thread worker = new Thread(() -> {
    try {
        Thread.sleep(10_000);
    } catch (InterruptedException e) {
        // throwing InterruptedException CLEARS the flag
        System.out.println(Thread.currentThread().isInterrupted());   // false
        Thread.currentThread().interrupt();                            // restore it
        System.out.println(Thread.currentThread().isInterrupted());   // true
    }
});
worker.start(); worker.interrupt();

// Case 2: the thread is busy computing -> it must check the flag itself
Thread loop = new Thread(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        // do a chunk of work
    }
    // clean up and exit
});

Daemon threads

The JVM exits when all non-daemon (user) threads have finished. Daemon threads are background helpers (GC, JIT compiler threads) that do not keep the JVM alive — when the last user thread ends, daemons are stopped abruptly, without running finally blocks.

Thread d = new Thread(() -> {
    try { Thread.sleep(60_000); } catch (InterruptedException e) {}
    System.out.println("never printed");
});
d.setDaemon(true);   // must be called BEFORE start()
d.start();
// main returns -> JVM exits immediately (our run finished in about 1 second, not 60)

Never use a daemon thread for work that must finish (writing a file, committing to a DB). A new thread inherits daemon status from the thread that created it.

29. synchronized, volatile & the Java Memory Model

Race condition: count++ loses updates

static int count = 0;

// 4 threads, each does count++ 100,000 times
Runnable inc = () -> { for (int i = 0; i < 100_000; i++) count++; };
Thread[] ts = new Thread[4];
for (int i = 0; i < 4; i++) { ts[i] = new Thread(inc); ts[i].start(); }
for (Thread t : ts) t.join();
System.out.println(count);   // expected 400000

Three real runs printed 135641, 128279 and 113633 — different every time, never 400000 (the exact number is nondeterministic). Why:

A race condition is any bug where the result depends on the timing of threads. The code read-modify-write (count++) and check-then-act (if (!map.containsKey(k)) map.put(k, v)) are the two classic shapes.

synchronized and intrinsic locks

Every Java object has a built-in lock called its intrinsic lock or monitor. synchronized acquires it on entry and releases it on exit — even if an exception is thrown.

class Counter {
    private int count;
    private final Object lock = new Object();

    public synchronized void inc() { count++; }        // locks 'this'
    public static synchronized void sInc() { }         // locks Counter.class (a different lock!)

    public void incBlock() {
        // ...work that needs no lock...
        synchronized (lock) {                          // locks only this block, on a private object
            count++;
        }
    }
}
// With synchronized: all our runs printed exactly 400000.

Reentrancy: a thread that already holds a lock can enter another block guarded by the same lock without deadlocking itself. The JVM keeps a hold count per owner.

static synchronized void outer() { inner(); }   // holds Counter.class lock
static synchronized void inner() { ... }        // same lock again: allowed, count goes to 2
// Without reentrancy, a synchronized method calling another would deadlock on itself,
// and so would a subclass overriding a synchronized method and calling super.

Pitfalls: locking on a boxed Integer or a String literal (shared across the JVM), locking on a field that gets reassigned, and guarding the same data with different locks in different places (no protection at all).

The visibility problem

static boolean flag = false;            // plain field
new Thread(() -> { while (!flag) { } System.out.println("saw flag"); }).start();
Thread.sleep(200);
flag = true;
// In our runs the reader was STILL spinning after 1 second, every time:
// the JIT turned the loop into "if (!flag) loop forever".

static volatile boolean vflag = false;  // volatile field
// Same code with vflag: "saw flag" printed and the thread ended right away.

(Whether the plain version hangs depends on the JIT and hardware — it is not guaranteed either way, which is exactly the problem.)

volatile

Marking a field volatile means: every read goes to the latest written value, every write becomes visible to other threads, and the compiler/CPU may not reorder other memory operations across it in unsafe ways. Use it for:

• Status flags: volatile boolean running, written by one thread and read by others.
• Publishing an immutable object: volatile Config current, replaced as a whole.
• The instance field in double-checked locking (below).

Why volatile does not make count++ atomic: count++ is still read, add, write — three separate steps. volatile makes each read and write fresh, but another thread can still write between your read and your write. Our run with volatile int printed 277680 (of 400000). Use synchronized or AtomicInteger for compound actions.

Happens-before, in easy words

"A happens-before B" is the JMM's promise: everything A's thread did before A is visible to B's thread after B. Without such a link, the other thread may see old values or see writes in a strange order. The main rules:

Also: final fields set in a constructor are visible to every thread once the constructor finishes (if this did not escape). Concurrent collections and executors document their own happens-before edges (putting into a ConcurrentHashMap hb getting it out).

int data; volatile boolean ready;
// Thread A                      // Thread B
data = 42;                       if (ready) {
ready = true;  // volatile write     System.out.println(data);   // guaranteed 42
                                 }
// The volatile write/read pair carries 'data' along with it.

Double-checked locking singleton

final class Config {
    private static volatile Config instance;          // volatile is ESSENTIAL
    private Config() { }

    static Config get() {
        Config local = instance;                      // one volatile read on the fast path
        if (local == null) {                          // check 1: no lock
            synchronized (Config.class) {
                local = instance;
                if (local == null) {                  // check 2: with lock
                    instance = local = new Config();
                }
            }
        }
        return local;
    }
}
// 4 threads calling Config.get() at once: constructor ran exactly once.

Why volatile? new Config() is allocate, run constructor, assign reference — and without volatile the CPU/JIT may assign the reference before the constructor finishes. Another thread passing check 1 would then get a half-built object. Simpler alternatives: the holder idiom (private static class Holder { static final Config I = new Config(); }, lazy and thread-safe thanks to class initialization) or an enum singleton.

wait / notify

wait, notify and notifyAll let threads coordinate on a condition ("buffer not empty") while holding the object's monitor.

final class Box {                       // bounded buffer, capacity 2
    private final Deque<Integer> q = new ArrayDeque<>();
    private final int cap = 2;

    synchronized void put(int v) throws InterruptedException {
        while (q.size() == cap) wait();  // releases the lock while waiting
        q.addLast(v);
        notifyAll();                     // wake consumers
    }
    synchronized int take() throws InterruptedException {
        while (q.isEmpty()) wait();
        int v = q.removeFirst();
        notifyAll();                     // wake producers
        return v;
    }
}
// Producer puts 1..5 then -1; consumer prints: 1 2 3 4 5

• Always call them inside synchronized on the same object, or you get IllegalMonitorStateException.
• Always wait in a while loop, never if: threads can wake spuriously, or another thread may grab the item first.
• Prefer notifyAll: notify wakes one arbitrary thread, which may be the wrong kind (a producer when a consumer was needed), causing a stall.
• In new code use BlockingQueue or Lock + Condition (section 30) instead.

30. Locks & Atomic Variables

ReentrantLock

final class Account {
    private final ReentrantLock lock = new ReentrantLock();
    private int balance = 100;

    boolean withdraw(int amt) {
        lock.lock();                  // outside the try
        try {
            if (balance < amt) return false;
            balance -= amt;
            return true;
        } finally {
            lock.unlock();            // ALWAYS in finally, or one exception locks it forever
        }
    }
}
// 4 threads x 10 withdrawals of 5 from 100: balance ends at 0, never negative.

ReentrantLock rl = new ReentrantLock();
rl.lock(); rl.lock();
rl.getHoldCount();    // 2  -- reentrant, just like synchronized; unlock twice

Its three extras, each verified while another thread was holding the lock:

// 1. tryLock: don't wait (or wait a bounded time) -- avoids deadlock, allows a fallback
lock.tryLock();                                // false (held by another thread)
lock.tryLock(100, TimeUnit.MILLISECONDS);      // false after 100 ms
if (lock.tryLock()) {
    try { /* work */ } finally { lock.unlock(); }
} else {
    // do something else, retry later, or report "busy"
}

// 2. lockInterruptibly: waiting can be cancelled with interrupt()
try {
    lock.lockInterruptibly();
    try { /* work */ } finally { lock.unlock(); }
} catch (InterruptedException e) {
    // "lockInterruptibly: gave up after interrupt"
    Thread.currentThread().interrupt();
}
// (A thread stuck in lock() or on synchronized ignores interrupts.)

// 3. Fairness: longest-waiting thread gets the lock next
ReentrantLock fair = new ReentrantLock(true);  // default is false (unfair = faster)

Fair vs unfair: an unfair lock lets a newly arriving thread "barge" ahead of the queue if the lock happens to be free — this avoids a context switch and gives much better throughput, but a thread can in theory wait a long time. Fair locks prevent starvation at a large speed cost. Keep the default unless you have measured starvation.

Condition — wait/notify for explicit locks

A Condition is a named wait-set tied to a lock. Unlike a monitor (which has one wait-set), a lock can have several, so producers and consumers wait on separate queues and signal wakes the right kind.

final class BoundedBuffer<T> {
    private final Deque<T> q = new ArrayDeque<>();
    private final int cap;
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull  = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();

    BoundedBuffer(int cap) { this.cap = cap; }

    void put(T t) throws InterruptedException {
        lock.lock();
        try {
            while (q.size() == cap) notFull.await();   // like wait(): releases the lock
            q.addLast(t);
            notEmpty.signal();                         // wake ONE consumer
        } finally { lock.unlock(); }
    }
    T take() throws InterruptedException {
        lock.lock();
        try {
            while (q.isEmpty()) notEmpty.await();
            T t = q.removeFirst();
            notFull.signal();                          // wake ONE producer
            return t;
        } finally { lock.unlock(); }
    }
}
// Producer puts 1..5 into a capacity-2 buffer; consumer's sum is 15.

This is essentially how ArrayBlockingQueue is built. Same rules as wait: hold the lock, and await in a while loop.

ReadWriteLock and StampedLock

// Many readers at once OR one writer -- good for read-heavy data
final class Cache {
    private final Map<String, String> map = new HashMap<>();
    private final ReadWriteLock rw = new ReentrantReadWriteLock();

    String get(String k) {
        rw.readLock().lock();
        try { return map.get(k); } finally { rw.readLock().unlock(); }
    }
    void put(String k, String v) {
        rw.writeLock().lock();
        try { map.put(k, v); } finally { rw.writeLock().unlock(); }
    }
}

A write lock can be downgraded to a read lock (take read, then release write), but a read lock can not be upgraded to write — trying it deadlocks. If reads are very short, the bookkeeping of a read-write lock can make it slower than a plain lock; measure first.

StampedLock (Java 8) adds an optimistic read: read without locking at all, then check that no writer came in; if one did, retry with a real read lock. Very fast for read-mostly data, but it is not reentrant, has no Condition, and is easy to misuse.

double distance() {
    long stamp = sl.tryOptimisticRead();     // no lock taken
    double cx = x, cy = y;                   // copy fields into locals
    if (!sl.validate(stamp)) {               // a writer slipped in -> fall back
        stamp = sl.readLock();
        try { cx = x; cy = y; } finally { sl.unlockRead(stamp); }
    }
    return Math.sqrt(cx * cx + cy * cy);     // after move(3, 4): 5.0
}

synchronized vs ReentrantLock

Default to synchronized for simple cases (shorter, can't forget to unlock). Reach for ReentrantLock when you need one of its extras — or with many virtual threads on Java 21.

Atomic variables and CAS

Compare-and-swap (CAS) is one CPU instruction that says: "if the value at this address is still expected, set it to new and tell me true; otherwise change nothing and tell me false." Because the check and the write happen as one indivisible step, no lock is needed.

AtomicInteger ai = new AtomicInteger();
// 4 threads x 100,000 ai.incrementAndGet()  ->  exactly 400000

AtomicInteger v = new AtomicInteger(5);
v.compareAndSet(5, 6);                  // true,  v = 6
v.compareAndSet(5, 7);                  // false, v still 6 (expected value was wrong)
v.updateAndGet(x -> x * 10);            // 60   (function may run more than once: keep it pure)
v.accumulateAndGet(42, Math::max);      // 60

// Writing the CAS loop by hand: square the value atomically
AtomicInteger m = new AtomicInteger(3);
int prev, next;
do {
    prev = m.get();
    next = prev * prev;
} while (!m.compareAndSet(prev, next));  // m = 9

AtomicReference<String> ref = new AtomicReference<>("v1");
ref.compareAndSet("v1", "v2");           // true -- compares REFERENCES (==), not equals()

Family: AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference, AtomicIntegerArray, and field updaters. ABA problem: a value goes A to B and back to A; a CAS expecting A succeeds even though things changed in between. It matters for lock-free linked structures; AtomicStampedReference fixes it by pairing the value with a version number.

LongAdder — for hot counters

Under heavy contention, many threads CAS-ing the same variable keep failing and retrying, and the cache line bounces between cores. LongAdder (Java 8) spreads the count over several internal cells (roughly one per contending thread) and only adds them up when you call sum().

LongAdder hits = new LongAdder();
hits.increment();          // cheap even with many threads
hits.add(5);
long total = hits.sum();   // not an atomic snapshot if updates are still happening

// Our rough run, 8 threads x 2,000,000 increments each:
//   AtomicLong 842 ms, LongAdder 124 ms   (both correct: 16000000)
// Timings vary by machine; the gap grows with the number of contending threads.

Use LongAdder for statistics counters that are written a lot and read rarely. Use AtomicLong when you need the exact current value on every update (like generating IDs) or compareAndSet.

When to use which

31. Executors & Thread Pools

The interfaces

The Executors factory methods — and their traps

I checked the first two rows with reflection on Java 21: the fixed pool's queue is a LinkedBlockingQueue with remainingCapacity() = 2147483647, and the cached pool uses a SynchronousQueue with maximum pool size 2147483647. That is why many style guides (Alibaba's Java manual is the famous one) forbid Executors.newXxx in production and ask you to build a ThreadPoolExecutor yourself so every limit is explicit.

How ThreadPoolExecutor decides what to do with a task

Building a pool the production way

ThreadPoolExecutor pool = new ThreadPoolExecutor(
        2,                                   // corePoolSize: threads kept alive even when idle
        4,                                   // maximumPoolSize: hard ceiling
        30, TimeUnit.SECONDS,                // keepAliveTime for threads above core
        new ArrayBlockingQueue<>(2),         // BOUNDED queue, capacity 2
        r -> new Thread(r, "worker-" + n.incrementAndGet()),   // name your threads!
        new ThreadPoolExecutor.AbortPolicy()); // what to do when full

// Submit 7 tasks that all block until we release them
for (int i = 1; i <= 7; i++) {
    try {
        pool.execute(blocker);
        System.out.printf("task %d accepted: threads=%d queued=%d%n",
                i, pool.getPoolSize(), pool.getQueue().size());
    } catch (RejectedExecutionException e) {
        System.out.println("task " + i + " REJECTED");
    }
}

Output (verified, deterministic because every task blocks on a latch):

task 1 accepted: threads=1 queued=0     <- core thread 1
task 2 accepted: threads=2 queued=0     <- core thread 2
task 3 accepted: threads=2 queued=1     <- core full, so queue
task 4 accepted: threads=2 queued=2     <- queue now full
task 5 accepted: threads=3 queued=2     <- extra thread
task 6 accepted: threads=4 queued=2     <- extra thread, max reached
task 7 REJECTED                         <- 4 running + 2 queued = capacity 6
terminated=true completed=6

Sizing a pool

• CPU-bound work (compression, math): about number of cores (or cores + 1). More threads only add context switches.
• I/O-bound work (HTTP, database): threads ≈ cores × (1 + wait time / compute time). A task that waits 90 ms and computes 10 ms on 8 cores → 8 × 10 = 80 threads. In Java 21, virtual threads are often simpler here (see s34).
• Always bound the queue and pick a rejection policy on purpose. Name threads with a ThreadFactory so thread dumps are readable.

submit vs execute

ExecutorService pool = Executors.newFixedThreadPool(2);
Future<Integer> f = pool.submit(() -> 10 / 0);
try {
    f.get();
} catch (ExecutionException e) {
    System.out.println("get() threw: " + e.getCause());
}
// get() threw: java.lang.ArithmeticException: / by zero

Future<String> ok = pool.submit(() -> "hello");
ok.get(1, TimeUnit.SECONDS);   // "hello" -- ALWAYS prefer the timeout version
ok.isDone();                   // true
// also: f.cancel(true) interrupts the running task; f.isCancelled()

invokeAll, invokeAny and scheduling

List<Callable<Integer>> tasks = List.of(() -> 1, () -> 2, () -> 3);
int sum = 0;
for (Future<Integer> r : pool.invokeAll(tasks)) sum += r.get();   // waits for ALL
// sum = 6; futures come back in the same order as the tasks
pool.invokeAny(tasks);   // result of ONE task that succeeded; the rest are cancelled

ScheduledExecutorService ses = Executors.newScheduledThreadPool(1);
ScheduledFuture<String> once = ses.schedule(() -> "ran after delay", 50, TimeUnit.MILLISECONDS);
once.get();   // "ran after delay"
ses.scheduleAtFixedRate(this::poll, 0, 20, TimeUnit.MILLISECONDS);     // start every 20 ms
ses.scheduleWithFixedDelay(this::poll, 0, 20, TimeUnit.MILLISECONDS);  // 20 ms gap AFTER each run ends

Fixed rate vs fixed delay: fixed rate keeps a steady clock (if a run is late, the next ones start back-to-back to catch up, never overlapping); fixed delay waits the full delay after each run ends. If a periodic task throws, all its future runs are cancelled silently — wrap the body in try/catch.

Shutting down

ExecutorService single = Executors.newSingleThreadExecutor();
single.submit(() -> { try { Thread.sleep(10_000); } catch (InterruptedException e) {
    System.out.println("running task interrupted"); } });
for (int i = 0; i < 3; i++) single.submit(() -> {});   // these wait in the queue

List<Runnable> neverRan = single.shutdownNow();   // prints "running task interrupted"
neverRan.size();                                   // 3
single.awaitTermination(1, TimeUnit.SECONDS);      // true

The standard pattern: shutdown(), then awaitTermination(timeout), and if it returns false, shutdownNow(). Pool threads are non-daemon, so forgetting to shut down a pool keeps the JVM alive after main ends. In Java 19+ you can write try (ExecutorService ex = ...) { ... } and close() does the shutdown and wait for you.

ForkJoinPool and work stealing

A ForkJoinPool gives each worker its own double-ended queue (deque). A task splits itself (fork) and pushes the halves onto its own deque; the owner pops from the top (newest, still-hot in cache). An idle worker steals from the bottom of someone else's deque (the oldest, usually biggest piece). Owners and thieves work at opposite ends, so they rarely collide.

class SumTask extends RecursiveTask<Long> {     // RecursiveAction if nothing is returned
    private static final int THRESHOLD = 10_000;
    private final long[] a; private final int lo, hi;
    SumTask(long[] a, int lo, int hi) { this.a = a; this.lo = lo; this.hi = hi; }

    @Override protected Long compute() {
        if (hi - lo <= THRESHOLD) {                // small enough: just do it
            long s = 0;
            for (int i = lo; i < hi; i++) s += a[i];
            return s;
        }
        int mid = (lo + hi) >>> 1;
        SumTask left = new SumTask(a, lo, mid);
        SumTask right = new SumTask(a, mid, hi);
        left.fork();                               // queue left half (may be stolen)
        long r = right.compute();                  // do right half in this thread
        return left.join() + r;                    // then collect left
    }
}
long[] data = new long[1_000_000];                 // 1..1,000,000
long total = ForkJoinPool.commonPool().invoke(new SumTask(data, 0, data.length));
// total = 500000500000

The common pool is shared by the whole JVM: parallel streams and CompletableFuture.supplyAsync without an executor both use it. Its parallelism is cores − 1 (verified: getParallelism() == availableProcessors() - 1 printed true). Never put blocking I/O on it — you starve every parallel stream in the application.

32. CompletableFuture

Starting async work

ExecutorService io = Executors.newFixedThreadPool(4, r -> new Thread(r, "io-pool"));

CompletableFuture<User> user = CompletableFuture.supplyAsync(() -> loadUser(1), io);  // returns a value
CompletableFuture<Void> log  = CompletableFuture.runAsync(() -> audit("login"), io);  // no value
CompletableFuture<String> ready = CompletableFuture.completedFuture("x");              // already done

// Manual completion -- bridge a callback API into a future
CompletableFuture<String> cf = new CompletableFuture<>();
client.onResponse(body -> cf.complete(body));
client.onError(ex -> cf.completeExceptionally(ex));

Without the second argument, supplyAsync runs on ForkJoinPool.commonPool(). For anything that blocks (HTTP, JDBC, files) always pass your own executor, otherwise a few slow calls block the shared pool used by parallel streams.

thenApply vs thenCompose vs thenCombine

// thenApply: transform the value
CompletableFuture<String> name = fetchUser(1, io).thenApply(User::name);
name.join();                                                        // "user1"

// If the function returns a future, thenApply NESTS it
CompletableFuture<CompletableFuture<Integer>> nested =
        fetchUser(2, io).thenApply(u -> fetchScore(u, io));        // awkward: join().join()
// thenCompose flattens it -- use it when step 2 depends on step 1's result
CompletableFuture<Integer> score = fetchUser(2, io).thenCompose(u -> fetchScore(u, io));
score.join();                                                       // 20

// thenCombine: both start now, combine when both are done
CompletableFuture<Integer> price = CompletableFuture.supplyAsync(() -> 100, io);
CompletableFuture<Double>  rate  = CompletableFuture.supplyAsync(() -> 0.9, io);
price.thenCombine(rate, (p, r) -> p * r).join();                    // 90.0

Waiting for many: allOf and anyOf

List<CompletableFuture<User>> fs = IntStream.rangeClosed(1, 3)
        .mapToObj(i -> fetchUser(i, io)).toList();

List<String> names = CompletableFuture.allOf(fs.toArray(new CompletableFuture[0]))  // CompletableFuture<Void>
        .thenApply(v -> fs.stream().map(CompletableFuture::join)   // join is instant: all are done
                                   .map(User::name).toList())
        .join();
// [user1, user2, user3]

CompletableFuture<Object> first = CompletableFuture.anyOf(slow, fast);   // Object, not T
first.join();   // "fast" (slow sleeps 300 ms; timing-based, but reliable in practice)

allOf returns Void — you collect results from the original futures. If any future fails, allOf fails too (after all have finished). anyOf completes with the first one to finish, even if that one failed.

Error handling: exceptionally, handle, whenComplete

CompletableFuture<Integer> boom = CompletableFuture.supplyAsync(() -> {
    throw new IllegalStateException("db down");
}, io);

boom.exceptionally(ex -> -1).join();                        // -1   (recover with a fallback)
// ex here is a CompletionException wrapping the IllegalStateException -- use ex.getCause()

boom.handle((v, ex) -> ex == null ? "ok " + v
                                  : "failed: " + ex.getCause().getMessage()).join();
// "failed: db down"   (always runs; sees value OR error; can change the result)

boom.whenComplete((v, ex) -> log(ex)).join();
// whenComplete only OBSERVES: join() still throws CompletionException (cause: db down)

boom.get();    // throws ExecutionException (checked)
boom.join();   // throws CompletionException (unchecked) -- nicer inside lambdas

An exception skips every thenApply/thenCompose step after it, until the first exceptionally/handle — exactly like a throw jumping to the nearest catch.

Which thread runs the callback?

CompletableFuture.completedFuture("x")
        .thenApply(s -> ...);        // already done: runs right now in the CALLER thread -> main

CompletableFuture.supplyAsync(() -> { sleep(100); return "y"; }, io)
        .thenApply(s -> ...);        // not done yet: runs in the thread that completes it -> io-pool

CompletableFuture.supplyAsync(() -> "z", io)
        .thenApplyAsync(s -> ...);   // *Async without executor -> ForkJoinPool.commonPool-worker-N
        // .thenApplyAsync(fn, io)   // *Async with executor   -> that executor

All three results above were printed by the verification run. Rule: a non-async callback runs in whichever thread happens to complete the previous stage, or in the thread that registers it if the stage is already done. You do not control it. If a callback is slow or blocking, use the ...Async(fn, executor) variant so it does not steal time from an I/O thread (for example, a Netty event loop).

Timeouts (Java 9)

CompletableFuture<String> slowCall = CompletableFuture.supplyAsync(() -> { sleep(500); return "real"; }, io);
slowCall.completeOnTimeout("fallback", 50, TimeUnit.MILLISECONDS).join();   // "fallback"

CompletableFuture<String> slowCall2 = CompletableFuture.supplyAsync(() -> { sleep(500); return "real"; }, io);
slowCall2.orTimeout(50, TimeUnit.MILLISECONDS).join();
// throws CompletionException, cause: java.util.concurrent.TimeoutException

Both complete the future; they do not stop the underlying work. The task keeps running on its thread until it finishes, and cancel(true) on a CompletableFuture does not interrupt it either. For real cancellation, make the task check a flag or use an HTTP client timeout.

A realistic pipeline

CompletableFuture<Dashboard> dashboard =
        CompletableFuture.supplyAsync(() -> userService.find(id), io)          // 1. user
            .thenCompose(user -> {
                var orders = CompletableFuture.supplyAsync(() -> orderService.recent(user), io);
                var recs   = CompletableFuture.supplyAsync(() -> recService.forUser(user), io);
                return orders.thenCombine(recs, (o, r) -> new Dashboard(user, o, r));  // 2. in parallel
            })
            .orTimeout(2, TimeUnit.SECONDS)                                     // 3. overall deadline
            .exceptionally(ex -> Dashboard.empty());                             // 4. degrade gracefully

Future vs CompletableFuture

Common pitfalls

• Calling join() too early: a.join(); b.join(); inside a loop makes the code sequential again. Start all futures first, then wait once with allOf.
• Forgetting the returned future: cf.thenApply(...) returns a new future. Handlers attached to the old one do not see errors thrown in the new step.
• Swallowed errors: a chain that ends in thenAccept and is never joined hides every exception. End chains with exceptionally or whenComplete that logs.
• Blocking in the common pool: JDBC calls inside supplyAsync with no executor starve parallel streams across the JVM.
• Deadlock by waiting on your own pool: a task in a 1-thread executor that calls join() on another task queued on the same executor waits forever.

33. Concurrent Collections

ConcurrentHashMap — how it works in Java 8+

Java 7 split the map into 16 "segments", each with its own lock. Java 8 threw that away. Now it is one array of bins (like HashMap) and:

• Reads never lock. The table and node values are read with volatile semantics, so get sees the latest completed write.
• Writing to an empty bin uses a single CAS (compare-and-swap, a lock-free CPU instruction) to install the first node.
• Writing to a non-empty bin locks only that bin with synchronized on its first node. Two threads writing different bins run in parallel.
• A bin with 8+ nodes becomes a red-black tree (TreeBin), same as HashMap.
• Resizing is shared: threads that arrive during a resize help move bins to the new table.
• size() sums per-thread counter cells (like LongAdder), so it is only an estimate while writes are happening.

Use the atomic methods — get-then-put is still a race

ConcurrentHashMap<String, Integer> chm = new ConcurrentHashMap<>();
ConcurrentHashMap<String, Integer> racy = new ConcurrentHashMap<>();
// 4 threads, each doing this 100,000 times:
chm.merge("hits", 1, Integer::sum);                  // atomic read-modify-write
racy.put("hits", racy.getOrDefault("hits", 0) + 1);  // two separate calls: NOT atomic

chm.get("hits");    // 400000
racy.get("hits");   // less than 400000 -- updates lost (true in every run; exact number varies)

Each single call on a ConcurrentHashMap is thread-safe, but a sequence of calls is not. Any "check then act" must be one call:

map.putIfAbsent(k, v);                                   // insert only if missing
map.computeIfAbsent(k, key -> new CopyOnWriteArrayList<>()).add(item);  // lazy create, once
map.compute(k, (key, old) -> old == null ? 1 : old + 1); // full control
map.merge(k, 1, Integer::sum);                           // counting
map.replace(k, expectedOld, newValue);                   // CAS-style update
// Bulk ops (Java 8) take a parallelism threshold:
long total = map.reduceValuesToLong(1, Integer::longValue, 0L, Long::sum);

The function passed to compute/merge runs while the bin is locked: keep it short, and never modify the same map from inside it (Java 9+ can throw IllegalStateException: Recursive update).

No null keys or values

chm.put("k", null);   // NullPointerException
chm.put(null, 1);     // NullPointerException
new HashMap<>().put(null, null);   // fine

Why? In a concurrent map, get(k) == null must mean "absent". If nulls were allowed you could not tell "absent" from "present with value null", and you cannot fix that with a follow-up containsKey because another thread may change the map in between.

Collections.synchronizedMap vs ConcurrentHashMap vs Hashtable

Map<String, Integer> sync = Collections.synchronizedMap(new HashMap<>());
synchronized (sync) {                        // required, or iteration can throw CME
    for (String k : sync.keySet()) { ... }
}
for (Integer k : chm.keySet()) chm.put(k + 10, 0);   // ConcurrentHashMap: no exception

Sorted and concurrent: ConcurrentSkipListMap / ConcurrentSkipListSet (O(log n), lock-free).

CopyOnWriteArrayList

Every write (add, set, remove) copies the whole internal array and swaps in the new one. Readers and iterators work on the old array — a snapshot — with no locking.

List<String> cow = new CopyOnWriteArrayList<>(List.of("a", "b"));
for (String s : cow) cow.add(s + "!");   // iterator sees the snapshot [a, b]
System.out.println(cow);                 // [a, b, a!, b!]  -- no exception, no infinite loop

List<String> al = new ArrayList<>(List.of("a", "b"));
for (String s : al) al.add(s);           // ConcurrentModificationException

Perfect for read-mostly lists: event listeners, config, routing tables. Terrible for write-heavy lists: each add is O(n) and creates garbage. The iterator does not support remove.

BlockingQueue and producer-consumer

A BlockingQueue adds methods that wait: put blocks while the queue is full, take blocks while it is empty. This is the safe way to hand work from one thread to another, and exactly what ThreadPoolExecutor uses inside.

private static final int POISON = -1;                 // "no more work" signal
BlockingQueue<Integer> queue = new ArrayBlockingQueue<>(3);   // bounded = back-pressure

Thread producer = new Thread(() -> {
    try {
        for (int i = 1; i <= 5; i++) queue.put(i);    // waits if 3 items are already queued
        queue.put(POISON);
    } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
});
Thread consumer = new Thread(() -> {
    try {
        int sum = 0;
        while (true) {
            int item = queue.take();                  // waits if empty
            if (item == POISON) break;
            System.out.println("consumed " + item);
            sum += item;
        }
        System.out.println("sum = " + sum);
    } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
});
producer.start(); consumer.start();
producer.join(); consumer.join();
// consumed 1 ... consumed 5, then: sum = 15   (FIFO order, so the output is deterministic)

Synchronizers: CountDownLatch, CyclicBarrier, Semaphore

// CountDownLatch: "wait until N things have happened" -- ONE-SHOT
CountDownLatch ready = new CountDownLatch(3);
for (String svc : List.of("db", "cache", "queue")) new Thread(ready::countDown).start();
ready.await();                 // main continues when the count hits 0

// CyclicBarrier: "N threads wait for EACH OTHER", then all go on -- REUSABLE
CyclicBarrier barrier = new CyclicBarrier(3, () -> System.out.println("phase finished by all"));
// each of 3 workers: for (int p = 0; p < 2; p++) barrier.await();
// prints "phase finished by all" twice: once per phase

// Semaphore: "at most N at a time" -- a pool of permits
Semaphore permits = new Semaphore(2);
permits.acquire();
try { callRateLimitedApi(); }
finally { permits.release(); }  // 6 tasks on 6 threads: max inside at once = 2 (verified)

Also know: Phaser (a flexible, reusable barrier with a changing number of parties) and Exchanger (two threads swap objects).

34. Virtual Threads & Deadlocks

Platform vs virtual threads

Using them

Thread vt = Thread.ofVirtual().name("my-virtual").start(() ->
        System.out.println("isVirtual=" + Thread.currentThread().isVirtual()));   // isVirtual=true
Thread.startVirtualThread(() -> work());              // shortest form
vt.isDaemon();                                        // true -- always daemon

// 10,000 tasks that each block for 1 second
try (ExecutorService ex = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> ex.submit(() -> {
        Thread.sleep(Duration.ofSeconds(1));          // virtual thread unmounts while sleeping
        return i;
    }));
}   // close() waits for all tasks
// Verified run: finished in 1407 ms. A fixed pool of 100 platform threads needs 100 rounds = ~100 s.

The model is "one virtual thread per task". Do not pool virtual threads — they are cheap to create and pooling defeats the purpose. To limit load on a downstream system, use a Semaphore, not a small pool.

When they help and when they don't

Virtual threads make blocking code cheap, not faster: a single request still takes as long. The win is that you can write simple blocking code instead of reactive/callback code and still handle huge concurrency.

Pinning

In Java 21, a virtual thread that blocks while inside a synchronized block (or a native method) cannot unmount — it pins its carrier thread. With only one carrier per core, a few pinned threads can stall the whole application.

synchronized (LOCK) {
    Thread.sleep(50);    // or a JDBC call -- pins the carrier in Java 21
}
// Run with -Djdk.tracePinnedThreads=short to detect it. Verified output:
// VirtualThread[#20]/runnable@ForkJoinPool-1-worker-1 reason:MONITOR
//     PinDemo.lambda$main$0(PinDemo.java:6) <== monitors:1

// Fix for Java 21: use a ReentrantLock, which virtual threads can unmount from
private final ReentrantLock lock = new ReentrantLock();
lock.lock();
try { callDatabase(); } finally { lock.unlock(); }

Java 24 (JEP 491) removed pinning for synchronized; on Java 21 it still matters, and interviewers like to ask.

Deadlock: the four conditions (Coffman)

A deadlock is possible only if all four hold. Break any one and it cannot happen.

A deadlock you can reproduce every time

static final Object A = new Object();
static final Object B = new Object();
CountDownLatch bothHoldFirstLock = new CountDownLatch(2);   // forces the bad timing

Thread t1 = new Thread(() -> {
    synchronized (A) {
        bothHoldFirstLock.countDown(); await(bothHoldFirstLock);
        synchronized (B) { System.out.println("t1 got both"); }   // never printed
    }
}, "t1");
Thread t2 = new Thread(() -> {
    synchronized (B) {                                          // OPPOSITE order
        bothHoldFirstLock.countDown(); await(bothHoldFirstLock);
        synchronized (A) { System.out.println("t2 got both"); }   // never printed
    }
}, "t2");
t1.start(); t2.start();
Thread.sleep(300);

// Detect it from inside the JVM -- the same check jstack runs
long[] ids = ManagementFactory.getThreadMXBean().findDeadlockedThreads();
// deadlocked threads: 2
// t1 state=BLOCKED waiting for lock owned by t2
// t2 state=BLOCKED waiting for lock owned by t1

Without the latch it is timing-dependent (it may run fine 999 times), which is exactly why deadlocks escape testing.

Fixes

// Fix 1: lock ordering -- always lock the lower id first
void transfer(Account from, Account to, long amount) {
    Account first  = from.id() < to.id() ? from : to;
    Account second = first == from ? to : from;
    synchronized (first) {
        synchronized (second) {
            from.withdraw(amount);
            to.deposit(amount);
        }
    }
}

// Fix 2: tryLock with timeout -- back off instead of waiting forever
static void transfer(Lock first, Lock second) throws InterruptedException {
    while (true) {
        if (first.tryLock(50, TimeUnit.MILLISECONDS)) {
            try {
                if (second.tryLock(50, TimeUnit.MILLISECONDS)) {
                    try { doWork(); return; }
                    finally { second.unlock(); }
                }
            } finally { first.unlock(); }
        }
        Thread.sleep(ThreadLocalRandom.current().nextInt(10));   // random back-off
    }
}
// Two threads calling this with the locks in OPPOSITE order: finishes, no deadlock (verified)

Other fixes: hold locks for as short a time as possible, never call unknown code (listeners, callbacks) while holding a lock, and prefer higher-level tools (ConcurrentHashMap, queues) over nested locks.

Livelock and starvation

• Livelock: threads are not blocked — they keep running — but make no progress, because each keeps reacting to the other. Two tryLock loops that back off and retry with the same fixed delay can keep colliding forever. Fix: random back-off (as above).
• Starvation: one thread never gets the resource because others always win — e.g. a greedy thread re-grabbing an unfair lock, or low-priority tasks behind an endless stream of high-priority ones. Fix: fair locks (new ReentrantLock(true)), bounded work per turn.

Detecting a deadlock in production: jstack

$ jps                      # find the process id
$ jstack <pid>             # or: jcmd <pid> Thread.print
Found one Java-level deadlock:
=============================
"t1":
  waiting to lock monitor 0x000000013210fdd0 (object 0x0000000787f14ac8, a java.lang.Object),
  which is held by "t2"

"t2":
  waiting to lock monitor 0x0000000132117100 (object 0x0000000787f14ab8, a java.lang.Object),
  which is held by "t1"

That is real output from a program that deadlocks (addresses differ per run). Look for threads in state BLOCKED (waiting for a monitor) or WAITING on a lock. Take 2–3 dumps a few seconds apart: a thread stuck on the same line in every dump is your suspect. VisualVM and JDK Mission Control also have a "detect deadlock" button.

35. JVM Memory: Heap, Stack & Metaspace

The runtime data areas

What lives where

Tracing one method call

void process() {
    int count = 3;                       // primitive: value lives IN the stack frame
    String name = "report";              // reference in the frame -> String object in the heap (pool)
    List<Integer> ids = new ArrayList<>(); // reference in the frame -> ArrayList object in the heap
    ids.add(count);                      // Integer object on the heap, referenced by the list's array
}   // frame popped: count, name, ids disappear; the ArrayList is now unreachable -> garbage

"Primitives live on the stack, objects live on the heap" is the right first answer, with two refinements: a primitive field of an object lives inside that object on the heap; and the JIT's escape analysis may avoid allocating an object on the heap at all if it never leaves the method (it replaces it with local scalars).

How an object is allocated

• Each thread gets a private chunk of Eden called a TLAB (thread-local allocation buffer). Allocating is just "bump a pointer" inside the thread's own TLAB — no locking, a few machine instructions. That is why new in Java is very cheap.
• Every object has a header (mark word for hash code, lock state and GC age, plus a pointer to its class): 12 bytes on a 64-bit JVM with compressed pointers, and objects are padded to multiples of 8 bytes. So an empty new Object() is 16 bytes and an Integer is 16 bytes to hold 4 bytes of data.
• Very large objects (bigger than half a G1 region) go straight into special humongous regions instead of Eden.
• Escape analysis: if the JIT proves an object never leaves the method, it can replace it with plain local variables (scalar replacement) — no heap allocation at all.

StackOverflowError vs OutOfMemoryError

static int depth = 0;
static void recurse() { depth++; recurse(); }   // no base case

try { recurse(); }
catch (StackOverflowError e) { System.out.println("StackOverflowError after ~" + (depth / 1000) * 1000 + " calls"); }

List<long[]> hog = new ArrayList<>();
try { while (true) hog.add(new long[1_000_000]); }   // 8 MB each, all still reachable
catch (OutOfMemoryError e) { hog = null; System.out.println(e.getMessage()); }

try { int[] huge = new int[Integer.MAX_VALUE]; }
catch (OutOfMemoryError e) { System.out.println(e.getMessage()); }

Verified with java -Xmx64m -Xss512k MemDemo:

StackOverflowError after ~6000 calls        (with -Xss2m: ~45000; varies run to run)
OutOfMemoryError: Java heap space after 7 blocks
OutOfMemoryError: Requested array size exceeds VM limit

Both are Errors, not Exceptions: you normally don't catch them. After an OOM the application may be in a broken state; let it crash, collect the heap dump, and restart.

The flags you should know

In servers, set -Xms equal to -Xmx so the heap never has to grow or shrink at runtime. Remember that the Java process uses more than -Xmx: metaspace, thread stacks, code cache, direct buffers and the GC's own structures all live outside the heap. Leave headroom in a container or the OS will kill the process (Kubernetes OOMKilled) without any Java error.

36. Garbage Collection

Reachability and GC roots

Because the JVM traces from roots, reference cycles are not a problem (unlike simple reference counting in, say, older Python or Objective-C). And System.gc() is only a hint; finalize() is deprecated (Java 9) and should never be used — use try-with-resources or Cleaner.

static class Node { Node other; }
Node a = new Node(), b = new Node();
a.other = b; b.other = a;                          // a cycle
WeakReference<Node> watchA = new WeakReference<>(a);   // watch without keeping it alive
a = null; b = null;                                // no root reaches the cycle any more
System.gc();
watchA.get() == null;                              // true -- the cycle was collected (verified)

The generational hypothesis

Studies of real programs show that most objects die young (temporary strings, iterators, request objects), and the few that survive a while tend to live a long time. So the heap is split into generations and the young one is collected often and cheaply.

The young collection is a copying collector: it copies the few live objects out and treats the whole of Eden as empty afterwards. Its cost depends on the number of live objects, not the amount of garbage — which is why short-lived garbage is almost free. The verified log below (G1, -Xmx64m -Xlog:gc, a loop allocating 200,000 temporary 1 KB arrays and keeping 200) shows each young GC shrinking the used heap from 38 MB to 1 MB in under a millisecond:

[0.005s][info][gc] Using G1
[0.040s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 24M->1M(64M) 0.888ms
[0.050s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 38M->1M(64M) 0.396ms
[0.056s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 38M->1M(64M) 0.493ms

Minor, major, full

The basic algorithm: mark, sweep, compact

Copying (used for the young generation) combines sweep and compact: copy live objects to an empty space and forget the old one. Fast when few survive, but needs spare space.

Stop-the-world

A stop-the-world (STW) pause is when the GC freezes all application threads (at "safepoints") so the object graph cannot change under it. Every HotSpot collector has some STW phases; modern ones do most of the work concurrently with the application and keep pauses short. Throughput (total work done) and latency (length of pauses) pull against each other: that trade-off is the whole reason for having several collectors.

The collectors

CMS (Concurrent Mark Sweep) was deprecated in Java 9 and removed in Java 14 — if you see it in old configs, it needs replacing with G1 or ZGC.

G1 in a little more depth

Because it cleans a few regions at a time and chooses how many from its pause target, G1 keeps pauses roughly predictable without compacting the whole heap. A full GC in G1 means it fell behind (allocation faster than concurrent marking could keep up, or no free regions for evacuation) — treat it as a signal to grow the heap or fix allocation.

Tuning basics

• Start with defaults. Set heap size (-Xms=-Xmx, or MaxRAMPercentage in containers) and choose the collector. Most apps need nothing else.
• Turn on GC logging (Java 9+ unified logging): -Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=20m. Analyze with GCeasy or GCViewer.
• Pauses too long on G1? Try lowering -XX:MaxGCPauseMillis, or move to ZGC. Frequent full GCs? Usually the heap is too small or there is a leak — tuning flags won't fix a leak.
• Allocate less: the cheapest GC is the one that doesn't happen. Avoid boxing in hot loops, reuse builders, stream instead of loading everything.

Reference types

Object strong = new Object();                                  // normal reference
WeakReference<Object> weak = new WeakReference<>(new Object()); // nothing else points to it
WeakReference<Object> weakButHeld = new WeakReference<>(strong);
SoftReference<byte[]> soft = new SoftReference<>(new byte[1024]);
ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantom = new PhantomReference<>(new Object(), queue);

System.gc();
weak.get() == null;          // true  -- cleared at the first GC
weakButHeld.get() == null;   // false -- still strongly reachable through 'strong'
soft.get() == null;          // false -- kept while memory is not low
phantom.get() == null;       // true  -- ALWAYS null; only tells you "it was collected"
queue.remove(1000) == phantom;   // true -- enqueued after collection

Map<Object, String> cache = new WeakHashMap<>();
Object key = new Object();
cache.put(key, "metadata");
key = null; System.gc();
cache.size();                // 0 -- entry vanished with its key

The results above are from a verified run (with G1, where System.gc() triggers a full collection; the spec does not guarantee it, so never rely on System.gc() in real code).

37. Class Loading

Three phases: loading, linking, initialization

• Loading: a class loader reads the bytes and creates a Class object. Metadata goes to metaspace.
• Verification: the bytecode verifier checks types, stack use and jumps are legal. This is why a hand-crafted .class file cannot corrupt the JVM.
• Preparation: static fields get memory and default values (static int x = 5; is 0 here).
• Resolution: symbolic names in the constant pool ("java/util/List") are turned into direct references, usually lazily when first used.
• Initialization: the compiler-generated <clinit> method runs — all static field initializers and static { } blocks, top to bottom. Now x becomes 5. The JVM guarantees this runs once, under a lock, so it is thread-safe.

The loaders and parent delegation

String.class.getClassLoader();                          // null      (bootstrap is native code)
java.sql.Connection.class.getClassLoader().getName();   // "platform"
LoaderDemo.class.getClassLoader().getName();            // "app"
app.getParent().getName();                              // "platform"
app.getParent().getParent();                            // null      (bootstrap)

(All verified on Java 21.) Before Java 9 the middle loader was the extension loader reading jre/lib/ext; the module system replaced it with the platform loader.

Why delegation? (1) Security: your own java.lang.String on the classpath is never used — the bootstrap loader already provided the real one (and the JVM refuses to define classes in java.* packages from other loaders). (2) No duplicates: a class is loaded once by the highest loader that can see it. (3) A class's identity is its name + its loader: the same .class loaded by two loaders gives two different classes, and casting between them throws ClassCastException (a classic app-server puzzle: "cannot cast com.x.Foo to com.x.Foo").

Some systems deliberately break delegation: Tomcat's web-app loaders look in the WAR first (so each app can have its own library versions), and JDBC's ServiceLoader uses the thread context class loader so JDK code can load driver classes from your classpath.

When does a static initializer run? (verified)

static class Config {
    static final int MAX = 10;               // compile-time constant: copied into the caller
    static int counter = 5;                  // NOT a constant
    static { System.out.println("  [Config static block runs]"); }
    static void hello() { System.out.println("  Config.hello()"); }
}
static class Parent { static { System.out.println("  [Parent init]"); } static int p = 1; }
static class Child extends Parent { static { System.out.println("  [Child init]"); } static int c = 2; }

System.out.println("1. read constant MAX = " + Config.MAX);   // no init
System.out.println("2. declare array");
Config[] arr = new Config[3];                                 // no init
System.out.println("3. Config.class literal: " + Config.class.getSimpleName());  // no init
System.out.println("4. read non-constant counter");
int x = Config.counter;                                       // init happens HERE
System.out.println("5. call static method");
Config.hello();                                               // no second init
System.out.println("6. Child.p (field declared in Parent)");
int y = Child.p;                                              // only Parent is initialised
System.out.println("7. new Child()");
new Child();
System.out.println("8. Class.forName initialises by default");
Class.forName("InitDemo$Lazy");

1. read constant MAX = 10
2. declare array
3. Config.class literal: Config
4. read non-constant counter
  [Config static block runs]
5. call static method
  Config.hello()
6. Child.p (field declared in Parent)
  [Parent init]
7. new Child()
  [Child init]
8. Class.forName initialises by default
  [Lazy init]

A class is initialized on its first active use: new, calling a static method, reading/writing a non-constant static field, initializing a subclass (the parent goes first), reflection like Class.forName(name), or being the main class. It is not initialized by reading a compile-time static final constant (inlined by javac), creating an array of it, Foo.class, or accessing a parent's static field through a child. Class.forName(name, false, loader) loads without initializing.

This laziness is what makes the holder idiom singleton work: the inner Holder class, and therefore the instance, is created only when getInstance() first touches it, and the JVM's init lock makes it thread-safe with no synchronized of your own.

public final class Registry {
    private Registry() {}
    private static class Holder { static final Registry INSTANCE = new Registry(); }
    public static Registry getInstance() { return Holder.INSTANCE; }
}

Writing a custom class loader

Override findClass, not loadClass. The inherited loadClass already does the delegation (check cache, ask parent, then call your findClass), so you keep the safety guarantees for free.

static class DirLoader extends ClassLoader {
    private final Path dir;
    DirLoader(Path dir, ClassLoader parent) { super(parent); this.dir = dir; }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // called only after the parent chain failed
        Path file = dir.resolve(name.replace('.', '/') + ".class");
        try {
            byte[] bytes = Files.readAllBytes(file);
            return defineClass(name, bytes, 0, bytes.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(name, e);
        }
    }
}

DirLoader l1 = new DirLoader(Path.of("plugins"), parent);
DirLoader l2 = new DirLoader(Path.of("plugins"), parent);
Class<?> c1 = l1.loadClass("Plugin");
Class<?> c2 = l2.loadClass("Plugin");
c1.getName().equals(c2.getName());          // true
c1 == c2;                                   // false -- different loaders, different classes
l1.loadClass("java.lang.String").getClassLoader() == null;   // true -- still delegated
c2.cast(c1.getDeclaredConstructor().newInstance());
// ClassCastException: Cannot cast Plugin to Plugin

This is how plugin systems, app servers and hot reload work: drop the loader (and every object from its classes), and the classes can be unloaded and reloaded fresh. Keep even one reference to an old object and the whole loader stays — the class loader leak from s38.

ClassNotFoundException vs NoClassDefFoundError

Class.forName("com.example.DoesNotExist");
// ClassNotFoundException: com.example.DoesNotExist

// Compiled UsesHelper + Helper, then deleted Helper.class:
// Exception in thread "main" java.lang.NoClassDefFoundError: Helper
//     at UsesHelper.main(UsesHelper.java:2)
// Caused by: java.lang.ClassNotFoundException: Helper

static class Broken {
    static int value = Integer.parseInt("not a number");   // static init throws
}
// first access:  ExceptionInInitializerError
// second access: NoClassDefFoundError   (the class is marked unusable forever)

The last case is a favourite trap: the log shows NoClassDefFoundError for a class that is clearly in the JAR. Scroll up to the first error — the real cause is the ExceptionInInitializerError from its static block.

38. Performance, Profiling & Memory Leaks

Common leak causes

The ThreadLocal leak you can see

static final ThreadLocal<String> CURRENT_USER = new ThreadLocal<>();
ExecutorService pool = Executors.newSingleThreadExecutor();     // ONE reused thread

pool.submit(() -> CURRENT_USER.set("alice")).get();            // request 1 forgets to clean up
pool.submit(() -> System.out.println("request 2 sees user = " + CURRENT_USER.get())).get();
// request 2 sees user = alice        -- a leak AND a security bug

pool.submit(() -> {
    CURRENT_USER.set("bob");
    try { /* handle request */ }
    finally { CURRENT_USER.remove(); }                         // always clean up
}).get();
pool.submit(() -> System.out.println("after remove(), user = " + CURRENT_USER.get())).get();
// after remove(), user = null

Inside, each thread has a ThreadLocalMap whose keys are weak references to the ThreadLocal but whose values are strong. The value lives as long as the thread — forever, in a pool.

The tools

Investigating a leak step by step

// The leak: a static cache that only grows
static final Map<String, Session> SESSIONS = new HashMap<>();
for (int i = 0; ; i++) {
    SESSIONS.put("s" + i, new Session("s" + i, new byte[10_000]));   // added on login, never removed
}

Real output from running the program above with -Xmx256m (3 seconds in):

$ jcmd <pid> GC.class_histogram
 num     #instances         #bytes  class name (module)
-------------------------------------------------------
   1:         19639       59593328  [B (java.base@21.0.7)          <- byte[] payloads
   2:           697         782256  [Ljdk.internal.vm.FillerElement; (java.base@21.0.7)
   3:         13657         327768  java.lang.String (java.base@21.0.7)
   4:          6920         221440  java.util.HashMap$Node (java.base@21.0.7)

$ jstat -gcutil <pid> 1000 3
  S0     S1     E      O      M     CCS    YGC     YGCT     FGC    FGCT     CGC    CGCT       GCT
     -      -  21.74  55.04  48.98   7.27      3     0.016     1     0.008     0     0.000     0.023
     - 100.00  12.50  64.49  48.98   7.27      4     0.019     1     0.008     2     0.000     0.027
     - 100.00  53.85  74.71  48.98   7.27      5     0.023     1     0.008     2     0.000     0.031

The O (old generation % used) column climbs 55 → 64 → 75 even though young GCs keep running: long-lived data is growing. Left alone, the run ended in OutOfMemoryError and, with -XX:+HeapDumpOnOutOfMemoryError, wrote a 270 MB .hprof. In MAT, the dominator tree would show one HashMap retaining nearly all of it, and "path to GC roots" leads to LeakDemo.SESSIONS. Note: GC.class_histogram forces a full GC (the FGC column shows 1), so be careful running it on a busy production box; heap dumps also pause the JVM and can be as large as the heap.

Where the time usually goes

JIT warm-up

The JVM starts by interpreting bytecode. Methods that run often ("hot") are compiled to machine code by the JIT (just-in-time) compiler — first quickly by C1, then with heavy optimization by C2 (inlining, escape analysis, loop unrolling), a scheme called tiered compilation. So a Java program gets faster after it has been running for a while.

for (int round = 1; round <= 5; round++) {
    long t0 = System.nanoTime();
    sink += work(2_000_000);                        // same work every round
    System.out.println("round " + round + ": " + (System.nanoTime() - t0) / 1000 + " us");
}
// Verified run (numbers vary by machine and run):
// round 1: 5573 us
// round 2: 4504 us
// round 3: 4002 us
// round 4: 3253 us
// round 5: 3241 us
// With -Xint (JIT disabled): about 28000 us every round

Consequences: benchmark numbers from a cold JVM are wrong; the first requests after a deploy are slower (warm the service up before routing traffic); and short-lived processes never get fully optimized (Java 21 options: CDS archives for start-up, GraalVM native image; Project Leyden continues this work).

Benchmarking correctly with JMH

A hand-written timing loop like the one above is misleading: no warm-up control, the JIT can remove work whose result is unused (dead-code elimination), it can fold constants, and GC pauses land at random. JMH (Java Microbenchmark Harness, from the OpenJDK team) handles all of this.

// Needs the org.openjdk.jmh:jmh-core and jmh-generator-annprocess dependencies
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1)        // let the JIT compile first
@Measurement(iterations = 5, time = 1)
@Fork(2)                                 // fresh JVMs, so one run's JIT choices don't leak into another
@State(Scope.Thread)
public class ConcatBench {
    @Param({"10", "1000"}) int n;

    @Benchmark
    public String plusInLoop() {
        String s = "";
        for (int i = 0; i < n; i++) s += i;
        return s;                        // RETURN the result so it can't be eliminated
    }

    @Benchmark
    public void builder(Blackhole bh) {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < n; i++) sb.append(i);
        bh.consume(sb.toString());       // or sink it into a Blackhole
    }
}

(This snippet is not in the verified set because it needs the JMH library; it follows the standard JMH API.) Before micro-optimizing anything, profile first (JFR or async-profiler) to find where time really goes — it is usually I/O, database queries, locks or allocation, not the loop you suspect.

39. Modern Java: 8 to 21

The feature timeline

Java 8 — lambdas, streams, Optional

List<String> names = List.of("anna", "bob", "carla", "dan");
List<String> longUpper = names.stream()
        .filter(n -> n.length() > 3)       // lambda
        .map(String::toUpperCase)           // method reference
        .toList();                          // [ANNA, CARLA]   (toList() is Java 16)

Optional<String> firstD = names.stream().filter(n -> n.startsWith("d")).findFirst();
firstD.map(String::length).orElse(0);       // 3

Java 10/11 — var, String helpers, HttpClient

var map = new HashMap<String, List<Integer>>();     // type inferred: HashMap<String, List<Integer>>
map.computeIfAbsent("a", k -> new ArrayList<>()).add(1);   // {a=[1]}
for (var e : map.entrySet()) System.out.println(e.getKey() + "->" + e.getValue());  // a->[1]

"  hi  ".strip();          // "hi"   (Unicode-aware, unlike trim)
" ".isBlank();             // true
"ab".repeat(3);            // "ababab"
"a\nb\nc".lines().count(); // 3

HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(5)).build();
HttpRequest req = HttpRequest.newBuilder(URI.create("http://127.0.0.1:" + port + "/hello")).GET().build();
HttpResponse<String> resp = client.send(req, HttpResponse.BodyHandlers.ofString());
System.out.println(resp.statusCode() + " " + resp.body());   // 200 {"msg":"hi"}

// Non-blocking version returns a CompletableFuture
String body = client.sendAsync(req, HttpResponse.BodyHandlers.ofString())
                    .thenApply(HttpResponse::body).join();

var is only for local variables with an initializer (not fields, parameters or return types). It is still static typing — the compiler fixes the type once. Use it when the right side already says the type (var list = new ArrayList<String>()); avoid it when it hides meaning (var x = service.process()).

Java 14 — switch expressions

int letters = switch (day) {
    case MON, FRI, SUN -> 6;          // several labels, no break needed
    case TUE -> 7;
    case THU, SAT -> 8;
    case WED -> {
        int n = "WEDNESDAY".length();
        yield n;                        // yield returns a value from a block
    }
};                                      // SAT -> 8

Arrow cases never fall through. For an enum, the compiler checks that every constant is covered, so no default is needed — and adding a new constant later becomes a compile error instead of a silent bug.

Java 15 — text blocks

String json = """
        {
          "name": "Ann",
          "age": 30
        }
        """;               // indentation up to the closing """ is stripped; 4 lines

Java 16 — records and instanceof patterns

record Point(int x, int y) {
    Point {                                   // compact constructor: validation only
        if (x < 0 || y < 0) throw new IllegalArgumentException("negative");
    }
    double dist() { return Math.sqrt(x * x + y * y); }
}
Point p = new Point(3, 4);
p + " " + p.x() + " " + p.dist() + " " + p.equals(new Point(3, 4));
// Point[x=3, y=4] 3 5.0 true   -- toString, accessors, equals/hashCode generated

Object o = "hello";
if (o instanceof String s && s.length() > 3) {   // s is bound only when the test succeeds
    System.out.println(s.toUpperCase());          // HELLO
}

Java 17 + 21 — sealed types, switch patterns, record patterns

sealed interface Shape permits Circle, Square, Rect {}
record Circle(double r) implements Shape {}
record Square(double side) implements Shape {}
record Rect(double w, double h) implements Shape {}

static double area(Shape s) {
    return switch (s) {                                   // exhaustive: no default needed
        case Circle c -> Math.PI * c.r() * c.r();          // type pattern
        case Square(double side) -> side * side;           // record pattern (deconstruction)
        case Rect(double w, double h) when w == h -> w * w; // guard with "when"
        case Rect(double w, double h) -> w * h;
    };
}
// Circle(1) 3.14, Square(2) 4.00, Rect(2,3) 6.00, Rect(3,3) 9.00

static String describe(Object o) {
    return switch (o) {
        case null -> "null!";                              // null can be a case now
        case Integer i when i > 100 -> "big int " + i;
        case Integer i -> "int " + i;
        case String s -> "string of length " + s.length();
        case Point(int x, int y) -> "point at " + x + "," + y;
        default -> "something else";
    };
}
// 42 -> int 42, 500 -> big int 500, "abc" -> string of length 3,
// Point(1,2) -> point at 1,2, null -> null!, 2.5 -> something else

if (obj instanceof Point(int x, int y)) System.out.println(x + y);   // 15 for Point(7, 8)

Order matters: a more specific case (Integer i when i > 100) must come before the general one, or the compiler reports it as dominated. Sealed + records + switch patterns together are called data-oriented programming: the data is plain, and the operations live in exhaustive switches the compiler checks.

Java 21 — sequenced collections

List<Integer> list = new ArrayList<>(List.of(1, 2, 3));
list.getFirst() + " " + list.getLast() + " " + list.reversed();   // 1 3 [3, 2, 1]

LinkedHashMap<String, Integer> lhm = new LinkedHashMap<>();
lhm.put("b", 2); lhm.put("a", 1); lhm.putFirst("z", 0);
lhm + " " + lhm.firstEntry() + " " + lhm.lastEntry();             // {z=0, b=2, a=1} z=0 a=1

LinkedHashSet<String> lhs = new LinkedHashSet<>(List.of("x", "y"));
lhs.addFirst("w");
lhs + " " + lhs.reversed();                                        // [w, x, y] [y, x, w]

New interfaces SequencedCollection, SequencedSet and SequencedMap give every ordered collection the same first/last/reversed methods. Before 21 you wrote list.get(list.size() - 1) or iterated a whole LinkedHashSet to find its last element. reversed() is a view, not a copy.

Java 21 — virtual threads

AtomicInteger done = new AtomicInteger();
try (var exec = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> exec.submit(() -> {
        Thread.sleep(Duration.ofMillis(100));   // blocking is cheap on a virtual thread
        done.incrementAndGet();
        return i;
    }));
}   // close() waits for every task
// 10000 tasks finished in well under 2 seconds on a laptop

Thread.ofVirtual().start(() -> System.out.println(Thread.currentThread().isVirtual()));  // true

A virtual thread is a thread managed by the JVM, not the OS. When it blocks (sleep, socket read, JDBC call) the JVM unmounts it from its carrier OS thread, which then runs another virtual thread. 10,000 platform threads would reserve about 1 MB of stack each (~10 GB of address space); 10,000 virtual threads cost a few MB. Use them for I/O-bound work (web requests, DB calls) — they do not make CPU-bound work faster. See section 34 for pinning and deadlocks.

40. I/O, NIO & Serialization

The class family

Byte vs character, with buffering

try (OutputStream out = new BufferedOutputStream(new FileOutputStream(bin.toFile()))) {
    out.write(new byte[]{72, 105});                  // raw bytes 'H' 'i'
}
try (InputStream in = new BufferedInputStream(new FileInputStream(bin.toFile()))) {
    int b;
    while ((b = in.read()) != -1) System.out.print(b + " ");   // 72 105
}

try (BufferedWriter w = Files.newBufferedWriter(txt, StandardCharsets.UTF_8)) {
    w.write("héllo"); w.newLine(); w.write("world"); w.newLine();
}
try (BufferedReader r = Files.newBufferedReader(txt, StandardCharsets.UTF_8)) {
    String line;
    while ((line = r.readLine()) != null) System.out.println("> " + line);
}
Files.size(txt);   // 13 bytes, not 12 -- 'é' takes 2 bytes in UTF-8

Why buffer? Each unbuffered read() can be a system call into the OS — thousands of times slower than reading from memory. A buffered stream reads 8 KB at once and serves later calls from that array. Always pass a charset for text: the platform default differed between machines before Java 18 (now UTF-8 by default), which caused "works on my laptop" bugs.

try-with-resources (Java 7)

Any object that implements AutoCloseable can go in the try (...) header. Java closes it automatically, in reverse order of opening, even when an exception is thrown. If close() also throws, that exception is suppressed and attached to the main one instead of hiding it.

static class Res implements AutoCloseable {
    final String n;
    Res(String n) { this.n = n; System.out.println("open " + n); }
    public void close() throws Exception { System.out.println("close " + n); throw new Exception("close failed " + n); }
}

try (Res a = new Res("A"); Res b = new Res("B")) {
    System.out.println("body");
    throw new IllegalStateException("body failed");
} catch (Exception e) {
    System.out.println("caught: " + e.getMessage());
    for (Throwable s : e.getSuppressed()) System.out.println("  suppressed: " + s.getMessage());
}

open A
open B
body
close B
close A
caught: body failed
  suppressed: close failed B
  suppressed: close failed A

Before Java 7 you wrote finally { if (in != null) in.close(); }, and an exception from close() would replace the real error. That is why try-with-resources is the only acceptable style today.

java.nio.file — Path and Files (the modern way)

Path f = dir.resolve("sub/list.txt");
Files.createDirectories(f.getParent());
Files.write(f, List.of("apple", "banana", "cherry"));          // lines, UTF-8
Files.writeString(f, "date\n", StandardOpenOption.APPEND);       // Java 11
List<String> all = Files.readAllLines(f);                       // [apple, banana, cherry, date]

try (Stream<String> lines = Files.lines(f)) {                   // lazy, MUST be closed
    lines.filter(s -> s.contains("an")).count();                // 1
}
try (Stream<Path> walk = Files.walk(dir)) {                     // recursive tree walk
    walk.filter(Files::isRegularFile)
        .map(p -> dir.relativize(p).toString())
        .sorted().forEach(System.out::println);
}   // data.bin  notes.txt  sub/list.txt  sub/one.txt

Path p = Path.of("/home/ann/docs/report.pdf");                  // Java 11 (Paths.get before)
p.getFileName() + " " + p.getParent() + " " + p.getNameCount(); // report.pdf /home/ann/docs 4
Path.of("/a/b").resolve("c/d.txt");                             // /a/b/c/d.txt
Path.of("/a/b/../c").normalize();                               // /a/c

NIO channels and buffers (in brief)

A channel (FileChannel, SocketChannel) is a two-way connection to a file or socket. You never read bytes from it directly — you read into a ByteBuffer. A buffer has a position (next slot), a limit (end of valid data) and a capacity. flip() switches it from writing mode to reading mode.

try (FileChannel fc = FileChannel.open(ch, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
    ByteBuffer buf = ByteBuffer.allocate(16);
    buf.put("NIO!".getBytes());      // position=4 limit=16
    buf.flip();                      // position=0 limit=4  -- now ready to be drained
    fc.write(buf);
}
try (FileChannel fc = FileChannel.open(ch, StandardOpenOption.READ)) {
    ByteBuffer buf = ByteBuffer.allocate(16);
    fc.read(buf);
    buf.flip();
    System.out.println(StandardCharsets.UTF_8.decode(buf));   // NIO!
}

Where NIO matters: non-blocking sockets with a Selector let one thread watch thousands of connections (this is how Netty, and therefore Spring WebFlux, work); FileChannel.transferTo does zero-copy file-to-socket transfer; memory-mapped files (fc.map) let huge files be treated as memory. For everyday file work, Files is enough.

Serialization: Serializable, serialVersionUID, transient

static class User implements Serializable {       // marker interface: no methods
    @Serial private static final long serialVersionUID = 1L;
    String name;
    transient String password;                     // skipped when writing
    int age;
}

try (var oos = new ObjectOutputStream(Files.newOutputStream(ser))) {
    oos.writeObject(new User("ann", "secret", 30));
}
try (var ois = new ObjectInputStream(Files.newInputStream(ser))) {
    User u = (User) ois.readObject();
    System.out.println(u);                         // ann/null/30  -- transient came back as null
}

• serialVersionUID is the class's version number. When reading, Java compares the stored UID with the current class's UID; if they differ you get InvalidClassException. If you don't declare one, Java computes it from the class shape, so adding a harmless method can break reading old data. Always declare it.
• transient fields are not written; on reading they get default values (null, 0, false). Use it for passwords, caches, and non-serializable fields like a Thread or DB connection. static fields are never serialized either (they belong to the class).
• Every field's type must also be Serializable, or you get NotSerializableException. During reading, the constructor of the first non-serializable superclass runs; the serializable class's own constructor does not.

Why Java serialization is discouraged

Alternatives: JSON with Jackson (the default in Spring), Protocol Buffers or Avro for compact typed binary between services, and plain database rows for persistence. If you must deserialize Java objects, set an ObjectInputFilter (Java 9) allow-list.

// Jackson 2.x -- works directly with records
public record User(String name, int age,
                   @JsonProperty("e_mail") String email,   // rename in JSON
                   @JsonIgnore String password) {}         // never written

ObjectMapper mapper = new ObjectMapper();                  // create once and reuse: thread-safe, expensive
mapper.writeValueAsString(new User("ann", 30, "ann@x.com", "secret"));
// {"e_mail":"ann@x.com","name":"ann","age":30}

mapper.readValue("{\"name\":\"bob\",\"age\":25,\"e_mail\":\"b@x.com\"}", User.class);
// User[name=bob, age=25, email=b@x.com, password=null]

41. Design Patterns in Java

Singleton — five ways

// 1) Eager: created when the class loads. Simple and thread-safe.
final class EagerSingleton {
    private static final EagerSingleton INSTANCE = new EagerSingleton();
    private EagerSingleton() {}
    static EagerSingleton getInstance() { return INSTANCE; }
}

// 2) Lazy: NOT thread-safe -- two threads can both see null and create two objects.
final class LazySingleton {
    private static LazySingleton instance;
    private LazySingleton() {}
    static LazySingleton getInstance() {
        if (instance == null) instance = new LazySingleton();
        return instance;
    }
}

// 3) Double-checked locking: lazy and fast, but volatile is essential.
final class DclSingleton {
    private static volatile DclSingleton instance;
    private DclSingleton() {}
    static DclSingleton getInstance() {
        DclSingleton local = instance;              // one volatile read on the fast path
        if (local == null) {                        // 1st check, no lock
            synchronized (DclSingleton.class) {
                local = instance;
                if (local == null)                  // 2nd check, under the lock
                    instance = local = new DclSingleton();
            }
        }
        return local;
    }
}

// 4) Holder idiom: lazy AND thread-safe with no locking code.
final class HolderSingleton {
    private HolderSingleton() { System.out.println("Holder instance created"); }
    private static class Holder { static final HolderSingleton INSTANCE = new HolderSingleton(); }
    static HolderSingleton getInstance() { return Holder.INSTANCE; }
}
// Calling another static method first prints nothing; the instance is created
// only on the first getInstance(), because Holder is loaded only then.

// 5) Enum: Joshua Bloch's recommended form. Serialization- and reflection-safe.
enum Registry {
    INSTANCE;
    private final Map<String, String> data = new HashMap<>();
    void put(String k, String v) { data.put(k, v); }
    String get(String k) { return data.get(k); }
}
Registry.INSTANCE.put("env", "prod");   // Registry.INSTANCE.get("env") -> prod

Why volatile in double-checked locking? instance = new DclSingleton() is three steps: allocate memory, run the constructor, assign the reference. Without volatile, the JIT or CPU may reorder so the reference is published before the constructor finishes; another thread passes the first null-check and uses a half-built object. volatile forbids that reordering (happens-before, section 29).

When to use: truly global, stateless or read-mostly things (config, a registry). Downsides: hidden global state, hard to mock in tests. In Spring apps you almost never write one — beans are singletons by default and are injected.

Builder

final class Pizza {
    private final String size; private final boolean cheese; private final List<String> toppings;
    private Pizza(Builder b) { size = b.size; cheese = b.cheese; toppings = List.copyOf(b.toppings); }
    static Builder builder(String size) { return new Builder(size); }   // required param up front

    static final class Builder {
        private final String size; private boolean cheese; private final List<String> toppings = new ArrayList<>();
        private Builder(String size) { this.size = Objects.requireNonNull(size); }
        Builder cheese() { cheese = true; return this; }            // return this -> chaining
        Builder topping(String t) { toppings.add(t); return this; }
        Pizza build() {
            if (toppings.size() > 3) throw new IllegalStateException("max 3 toppings");  // validate once
            return new Pizza(this);
        }
    }
}
Pizza.builder("large").cheese().topping("olives").topping("basil").build();
// Pizza[large, cheese=true, [olives, basil]]

When: four or more parameters, many optional. It beats "telescoping constructors" (Pizza(size), Pizza(size, cheese), …) and produces an immutable object. For two or three fields, a record is simpler.

Factory (simple factory and Factory Method)

interface Notifier { String send(String msg); }
record EmailNotifier() implements Notifier { public String send(String m) { return "EMAIL: " + m; } }
record SmsNotifier()   implements Notifier { public String send(String m) { return "SMS: " + m; } }

// Simple (static) factory: one place decides the concrete class
static Notifier create(String channel) {
    return switch (channel) {
        case "email" -> new EmailNotifier();
        case "sms"   -> new SmsNotifier();
        default      -> throw new IllegalArgumentException("unknown channel " + channel);
    };
}
create("email").send("hi");                 // EMAIL: hi

// GoF Factory Method: a subclass overrides the creation step
abstract class Dialog {
    abstract Notifier createNotifier();     // the factory method
    String alert(String m) { return createNotifier().send(m.toUpperCase()); }
}
class SmsDialog extends Dialog { Notifier createNotifier() { return new SmsNotifier(); } }
new SmsDialog().alert("server down");      // SMS: SERVER DOWN

When: the caller should depend on an interface, and the choice of class depends on input or configuration. Static factory methods also get good names (Optional.empty(), Duration.ofSeconds) and can return cached instances.

Strategy — with lambdas

interface DiscountStrategy { double apply(double price); }       // a functional interface
record Checkout(DiscountStrategy strategy) {
    double total(double price) { return strategy.apply(price); }
}
Map<String, DiscountStrategy> strategies = Map.of(
        "none",       p -> p,
        "tenPercent", p -> p * 0.9,
        "flat5",      p -> Math.max(0, p - 5));
new Checkout(strategies.get("tenPercent")).total(100);   // 90.0
// none -> 100.0, flat5 -> 95.0

When: you see a growing if/else or switch choosing between algorithms (pricing rules, sorting, compression). Before Java 8 each strategy was a class; now it is usually a lambda. Comparator is the Strategy everyone already uses.

Observer

final class StockTicker {
    private final List<Consumer<Double>> listeners = new ArrayList<>();
    void subscribe(Consumer<Double> l) { listeners.add(l); }
    void setPrice(double p) { listeners.forEach(l -> l.accept(p)); }   // push to all
}
StockTicker t = new StockTicker();
List<Double> history = new ArrayList<>();
t.subscribe(p -> System.out.println("display: " + p));
t.subscribe(history::add);
t.subscribe(p -> { if (p > 150) System.out.println("ALERT: price above 150"); });
t.setPrice(120.0); t.setPrice(155.5);
// display: 120.0 / display: 155.5 / ALERT: price above 150 ; history = [120.0, 155.5]

When: one change must reach many independent parts that the source should not know about. Pitfalls: forgetting to unsubscribe (a classic memory leak), and a slow listener blocking the others. For thread safety use CopyOnWriteArrayList for the listener list. At system scale, the same idea becomes pub/sub with Kafka.

Decorator — the java.io example

interface Coffee { double cost(); String desc(); }
record Espresso() implements Coffee { public double cost() { return 2.0; } public String desc() { return "espresso"; } }
record Milk(Coffee inner) implements Coffee {
    public double cost() { return inner.cost() + 0.5; } public String desc() { return inner.desc() + " + milk"; } }
record Syrup(Coffee inner) implements Coffee {
    public double cost() { return inner.cost() + 0.7; } public String desc() { return inner.desc() + " + syrup"; } }
Coffee c = new Syrup(new Milk(new Espresso()));
c.desc() + " = " + c.cost();                 // espresso + milk + syrup = 3.2

// java.io uses exactly this: FilterReader is the decorator base class
final class CountingReader extends FilterReader {
    int count;
    CountingReader(Reader in) { super(in); }
    @Override public int read(char[] b, int off, int len) throws IOException {
        int n = super.read(b, off, len); if (n > 0) count += n; return n; }
    // (single-char read() overridden the same way)
}
try (CountingReader cr = new CountingReader(new StringReader("line one\nline two\n"));
     BufferedReader br = new BufferedReader(cr)) {       // decorator on a decorator
    while (br.readLine() != null) { }
    System.out.println(cr.count);                        // 18
}

When: you need combinations of extra behaviours (buffering + decoding + counting) without a subclass for every combination. Decorator vs inheritance: inheritance fixes behaviour at compile time; decorators compose at runtime.

Adapter

final class LegacyThermometer { double readFahrenheit() { return 98.6; } }   // can't change it
interface CelsiusSensor { double celsius(); }                                // what our code wants

record ThermometerAdapter(LegacyThermometer legacy) implements CelsiusSensor {
    public double celsius() { return (legacy.readFahrenheit() - 32) * 5 / 9; }
}
new ThermometerAdapter(new LegacyThermometer()).celsius();   // 37.0

When: integrating a third-party or legacy API whose shape does not match your interface. Adapter changes the interface; Decorator keeps the interface and adds behaviour. JDK examples: Arrays.asList (array to List), InputStreamReader (byte stream to character stream).

Template Method

abstract class DataImporter {
    final List<String> run(String raw) {                 // final: the skeleton cannot change
        List<String> rows = parse(raw);
        rows = rows.stream().filter(this::isValid).toList();
        log(rows.size() + " rows imported");
        return rows;
    }
    protected abstract List<String> parse(String raw);   // required step
    protected boolean isValid(String row) { return !row.isBlank(); }   // optional "hook"
    private void log(String m) { System.out.println("[" + getClass().getSimpleName() + "] " + m); }
}
class CsvImporter extends DataImporter {
    protected List<String> parse(String raw) { return List.of(raw.split(",")); }
}
class LineImporter extends DataImporter {
    protected List<String> parse(String raw) { return raw.lines().toList(); }
    @Override protected boolean isValid(String row) { return !row.startsWith("#"); }
}
new CsvImporter().run("a,,b, ,c");        // [CsvImporter] 3 rows imported -> [a, b, c]
new LineImporter().run("x\n#comment\ny"); // [LineImporter] 2 rows imported -> [x, y]

When: several classes share the same steps in the same order but differ in one or two steps. Modern alternative: pass the varying step as a lambda (Strategy) — favour composition when there is only one varying step.

42. SOLID in Java

S — Single Responsibility

// BEFORE: calculation, formatting and persistence in one class -- three reasons to change
class InvoiceBefore {
    double amount;
    double total() { return amount * 1.2; }
    String toHtml() { return "<p>" + total() + "</p>"; }
    void saveToDb() { /* JDBC code */ }
}

// AFTER: one job each
record Invoice(double amount) { double total() { return amount * 1.2; } }
class InvoiceHtmlPrinter { String print(Invoice i) { return "<p>" + i.total() + "</p>"; } }
interface InvoiceRepository { void save(Invoice i); }
class InMemoryInvoiceRepository implements InvoiceRepository {
    final List<Invoice> saved = new ArrayList<>();
    public void save(Invoice i) { saved.add(i); }
}
// new InvoiceHtmlPrinter().print(new Invoice(100)) -> <p>120.0</p>

"One reason to change" means one actor: the tax team changes total(), the design team changes the HTML, the DBA changes storage. When they share a class, their edits collide. Smell: a class named ...Manager or ...Utils with 40 methods.

O — Open/Closed

// BEFORE: every new shape means editing (and re-testing) this method
static double areaBefore(Object shape) {
    if (shape instanceof double[] circle) return Math.PI * circle[0] * circle[0];
    // else if square ... else if triangle ... keeps growing
    throw new IllegalArgumentException();
}

// AFTER: open for extension (new class), closed for modification
interface Shape { double area(); }
record Circle(double r) implements Shape { public double area() { return Math.PI * r * r; } }
record Square(double s) implements Shape { public double area() { return s * s; } }
static double totalArea(List<Shape> shapes) { return shapes.stream().mapToDouble(Shape::area).sum(); }
// totalArea(List.of(new Circle(1), new Square(2))) -> 7.14

Tools for OCP in Java: interfaces + polymorphism, Strategy (a lambda per rule), and Spring injecting a List<Handler> of all beans of a type. Java 21 nuance: for a closed set of types (sealed), an exhaustive switch is fine — the compiler forces you to update every switch when a type is added.

L — Liskov Substitution

// BEFORE: Square "is a" Rectangle in maths, but not in code
class Rectangle {
    protected int w, h;
    void setWidth(int w) { this.w = w; }
    void setHeight(int h) { this.h = h; }
    int area() { return w * h; }
}
class SquareBad extends Rectangle {
    @Override void setWidth(int w)  { this.w = w; this.h = w; }
    @Override void setHeight(int h) { this.w = h; this.h = h; }
}
static int resizeAndMeasure(Rectangle r) { r.setWidth(5); r.setHeight(4); return r.area(); }
resizeAndMeasure(new Rectangle());   // 20
resizeAndMeasure(new SquareBad());   // 16  -- caller's expectation broken

// AFTER: no inheritance between them; immutable siblings under one interface
record Rect(int w, int h) implements Shape { public double area() { return w * h; } }
record Sq(int side)       implements Shape { public double area() { return side * side; } }

A subclass must not strengthen preconditions (accept less), weaken postconditions (promise less) or throw new unchecked surprises. JDK violation everyone knows: List.of(...) is a List, but add throws UnsupportedOperationException.

I — Interface Segregation

// BEFORE: fat interface forces fake implementations
interface WorkerBefore { void work(); void eat(); }
class RobotBefore implements WorkerBefore {
    public void work() {}
    public void eat() { throw new UnsupportedOperationException("robots don't eat"); }
}

// AFTER: small role interfaces; implement only what applies
interface Workable { String work(); }
interface Eatable  { String eat(); }
class Human implements Workable, Eatable {
    public String work() { return "human works"; } public String eat() { return "human eats"; } }
class Robot implements Workable { public String work() { return "robot works"; } }
List<Workable> workers = List.of(new Human(), new Robot());   // human works, robot works