Top 10 Essential Java Interview Questions: Fundamentals Edition

Java Basics – High‑Frequency Interview Topics

1. Parameter passing: value vs. reference

Java uses only pass‑by‑value.

Primitive types – a copy of the actual value is passed.

Reference types – a copy of the reference (the address) is passed.

public void test() {
    int a = 1;
    change(a);
    System.out.println(a); // 1, unchanged

    User user = new User("张三");
    change(user);
    System.out.println(user.getName()); // 李四, object field changed
}

void change(int a) { a = 2; }

void change(User user) { user.setName("李四"); }

Extra point: The copied reference allows mutation of the object's fields but cannot reassign the reference itself.

2. String, StringBuilder, StringBuffer

Mutability : String is immutable; StringBuilder and StringBuffer are mutable.

Thread safety : String is inherently safe; StringBuilder is not thread‑safe; StringBuffer is synchronized and thus thread‑safe.

Performance : String – low (creates new objects on each modification); StringBuilder – high (no synchronization); StringBuffer – medium (synchronization overhead).

Typical use cases : String for rarely‑changing text; StringBuilder for single‑thread concatenation; StringBuffer for multi‑thread concatenation.

Extra point: String is immutable because its internal char[] array is declared final and no mutating methods are provided. Concatenation always creates a new object, so loops should use StringBuilder (or StringBuffer when thread safety is required).

3. == vs. equals()

Primitive types : == compares the actual values.

Reference types : == compares memory addresses; equals() (when overridden) compares logical content.

String example :

String a = new String("hello");
String b = new String("hello");

System.out.println(a == b);        // false, different objects
System.out.println(a.equals(b)); // true, same content

Extra point: When overriding equals(), you must also override hashCode(); otherwise hash‑based collections such as HashMap cannot locate the object correctly.

4. Relationship between hashCode() and equals()

Consistency principle : If obj1.equals(obj2) returns true, then obj1.hashCode() must equal obj2.hashCode().

Reverse is not required : Equal hash codes do not guarantee equals() returns true.

Default implementation : Object.hashCode() returns a value derived from the object's memory address when not overridden.

Extra point: HashMap first computes the bucket using hashCode() and then uses equals() for equality checks. Overriding only equals() can cause lookup failures.

5. final , finally , finalize

final

: Modifies classes (cannot be subclassed), methods (cannot be overridden), and variables (cannot be reassigned). finally: A block that executes after try / catch regardless of whether an exception occurs; it runs before a return in the try block, but a return inside finally overrides the earlier return. finalize: An Object method invoked by the garbage collector before object reclamation; deprecated since Java 9 and not recommended for use.

6. Interface vs. abstract class

Keyword : interface vs. abstract.

Inheritance : Abstract class – single inheritance; interface – multiple inheritance (a class can implement many interfaces).

Constructors : Abstract classes can define constructors; interfaces cannot.

Member variables : Abstract class – any visibility; interface – implicitly public static final.

Methods : Abstract class – abstract, concrete, static; interface – abstract (implicitly), default, static, and since Java 9, private methods.

Extra point: Java 8 introduced default and static methods in interfaces; Java 9 added private methods. Interfaces support multiple inheritance, while abstract classes allow only single inheritance.

7. Four reference types in Java

Strong reference : Default; objects are never reclaimed while reachable.

Soft reference : Reclaimed only under memory pressure; suitable for caches.

SoftReference<Object> ref = new SoftReference<>(new Object());
Object obj = ref.get(); // may be null if memory is low

Weak reference : Reclaimed on any GC cycle; used by ThreadLocal for keys.

WeakReference<Object> ref = new WeakReference<>(new Object());
// After GC, ref.get() returns null

Phantom reference : The weakest; cannot retrieve the referent; used for tracking object finalization.

Extra point: ThreadLocal stores its keys as WeakReference to avoid memory leaks, while the values remain strong references and must be removed manually.

8. Static inner class vs. non‑static inner class

Declaration : Static inner class uses the static modifier; non‑static (member) inner class does not.

Outer reference : Static inner class does not hold a reference to the outer instance; non‑static inner class holds an implicit reference to its enclosing object.

Instantiation :

Static: new Outer.Inner() Non‑static: new Outer().new Inner() Access : Static inner class can access only static members of the outer class; non‑static inner class can access both static and instance members.

Memory footprint : Static inner class is smaller because it does not retain the outer instance; non‑static inner class is larger.

Extra point: Because a static inner class does not retain a reference to the outer class, it avoids memory leaks and is the preferred way to implement singletons.

9. Generics and type erasure

Generics : Parameterized types that provide compile‑time type safety.

Type erasure : The compiler removes generic type information, replacing it with Object or the bounded type.

List<String> list1 = new ArrayList<>();
List<Integer> list2 = new ArrayList<>();
// After compilation both are List<Object>
System.out.println(list1.getClass() == list2.getClass()); // true

Extra point: Java uses type erasure to maintain backward compatibility with code written before JDK 1.5.

10. Exception hierarchy

Throwable
├── Error (system errors, unrecoverable)
│   ├── OutOfMemoryError
│   ├── StackOverflowError
│   └── ...
└── Exception
    ├── RuntimeException (unchecked)
    │   ├── NullPointerException
    │   ├── IllegalArgumentException
    │   └── ...
    └── Checked exceptions
        ├── IOException
        ├── SQLException
        └── ...

Checked vs. unchecked :

Checked exceptions (subclass of Exception excluding RuntimeException) must be declared or caught at compile time.

Unchecked exceptions ( RuntimeException and its subclasses) are optional to handle.

Typical handling : try‑catch or throws for checked exceptions; optional for unchecked.

Extra point: Custom business exceptions are often derived from RuntimeException to reduce boilerplate handling code.