Java Language

Java vs JVM vs ART vs Kotlin

Java is a language: source files, types, the standard library, and a set of contracts (equals, exceptions, the memory model). The JVM is a specification for a virtual machine that loads class files, verifies bytecode, JIT-compiles hot methods, and manages a garbage-collected heap. HotSpot is the usual desktop and server implementation. ART (Android Runtime) is Android's implementation of a Java-like VM: it still runs JVM bytecode in spirit, but the on-disk format is dex, the compiler is dex2oat, and the GC and JIT/AOT story is tuned for phones, not servers.

The JRE is a runtime (VM + class library) used to run programs. The JDK is the JRE plus tools: javac, javap, jar, a debugger. Saying "I installed Java" without saying JDK vs JRE is sloppy.

Kotlin is a different language that compiles to JVM bytecode (and to dex on Android). It can call Java and be called from Java. This page is Java. When an interviewer says "Kotlin on Android", they still expect you to know ART, the heap, and Binder; they do not expect a Kotlin language lecture here.

Source (.java)  --javac-->  JVM bytecode (.class)
Kotlin  (.kt)   --kotlinc-->  JVM bytecode (.class)
On Android: .class / .jar  --d8/r8-->  dex  --dex2oat-->  oat/vdex  --ART-->  native + interp
On a server: .class  --HotSpot classload + JIT/AOT-->  native

Compilation and class loading

javac turns .java into class files: a header, a constant pool, field and method descriptors, and bytecode for each method. It does not produce machine code. javap -c -p is the tool that proves you can read what the compiler emitted. The VM then loads, links and initializes each class the first time it is needed.

From source to a live Class object

1. Compile javac emits bytecode. Overload resolution, generic erasure and checked-exception rules happen here.
2. Load A classloader finds bytes (disk, dex, network) and defines a Class. On Android the defining loader works from dex, not a tree of .class files.
3. Link: verify The VM checks that bytecode is type-safe and does not smash the stack. ART can persist verification in a vdex so it is not repeated every boot.
4. Link: prepare Static fields get default values (0, null, false).
5. Link: resolve Symbolic refs in the constant pool become concrete classes, fields and methods, often lazily on first use.
6. Initialize Superclass first, then static initializers and static field assignments, in textual order, under a class lock. The JLS forbids seeing a class half-initialized from another thread.

Classloaders and parent delegation

A class is identified by its binary name plus its defining classloader. The bootstrap loader loads java.lang.*. The platform (extension) loader loads remaining JDK modules. The application (system) loader loads the classpath or module path. Each loader asks its parent first (parent delegation) so that java.lang.String is never replaced by a classpath impostor.

On Android, the app's PathClassLoader (or a descendant) loads the APK's dex. Shared framework classes come from the boot image Zygote already mapped. Plugin or hot-fix loaders are a common leak source: they pin the old APK's classes if any static or thread outlives the unload.

request load "com.example.Foo"
        │
        ▼
app loader ──ask parent──▶ platform ──ask parent──▶ bootstrap
        │                      │                         │
        │                      │                    java.*, core
        │                 jdk.* if not bootstrap
        └── define Foo from app dex if parents said no

Static vs instance; initialization order

Static fields and static blocks belong to the class; they run once when the class is initialized. Instance fields, instance blocks and constructors run on every new. Order for a new object:

1. Superclass initialize if not already done (static side).
2. This class initialize static fields and static { } in source order.
3. Super constructor chain after the implicit or explicit super() (or this()) call.
4. This class instance fields and { } blocks in source order, then the rest of the constructor body.

class Animal {
  static { System.out.println("Animal static"); }
  { System.out.println("Animal instance"); }
  Animal() { System.out.println("Animal ctor"); }
}
class Cat extends Animal {
  static { System.out.println("Cat static"); }
  { System.out.println("Cat instance"); }
  Cat() { System.out.println("Cat ctor"); }
}
// new Cat() prints:
// Animal static, Cat static, Animal instance, Animal ctor, Cat instance, Cat ctor

The first use that triggers initialization is a defined list: new, a static method or field (except final compile-time constants), or a reflective force. Reading public static final int N = 3; from another class does not initialize the declaring class; the constant was inlined.

Memory layout: stack, heap, headers, generations

Each thread has a Java stack of frames. A frame holds local variables (including this and parameters) and an operand stack for bytecode. Locals that are object types are references, not the objects. Objects, arrays and class objects live on the heap. Native stacks (JNI, VM internals) sit beside the Java stack. Method metadata and class metadata live outside the Java heap: Metaspace on HotSpot, native linear-alloc on ART.

Thread T1 stack          Heap                         Metadata (native)
+-----------------+      +----------------------+     +-----------------+
| frame bar()     |      | object header +      |     | Klass / methods |
|   Point p  -----+------>| fields x, y          |     | constant pool   |
| frame foo()     |      | String "hi"          |     | (Metaspace/ART) |
|   int n = 3     |      | array, Class<Foo>    |     +-----------------+
+-----------------+      +----------------------+

Object header

A typical HotSpot object starts with a mark word (identity hash, GC age, lock bits) and a class pointer (which Klass this is). Then come the fields, then padding to the alignment (often 8 bytes). Arrays add a length. Compressed ordinary object pointers (oops) pack heap refs into 32 bits when the heap is under about 32 GB. Compressed class pointers pack the class word similarly. ART's object header is a different layout (lock word, class pointer, optional monitor) but the interview idea is the same: every object pays a fixed header tax before its fields.

HotSpot generations vs ART

HotSpot historically splits the heap into a young generation (Eden plus two Survivor spaces) and an old (tenured) generation. Most objects die in Eden. Survivors that live long enough are promoted. G1 (the default since Java 9) still uses young/old roles but the heap is a grid of equal-sized regions. ZGC and Shenandoah aim at short pauses with concurrent relocation.

ART on modern Android uses a moving Concurrent Copying (CC) collector: bump-pointer allocation into a young region, concurrent marking and copying, short stop-the-world (STW) roots. Older ART used concurrent mark-sweep. Zygote's preloaded objects sit in an image space that is almost never compacted, so copy-on-write pages stay shared across apps. Do not recite G1 Eden/Survivor as if it were the phone.

Escape analysis

If the JIT proves an object never escapes the method or thread (no store to a heap field, no pass to an unknown method), it may scalar-replace it: the object never exists on the heap; its fields become registers or stack slots. That is why a tiny new Point(x, y) in a hot loop can be free, and why you should not micro-optimise allocations the compiler already elides. Escape analysis is a HotSpot JIT feature; ART's JIT can do similar scalar replacement on some shapes, but you must not claim "Java never allocates" without a profiler.

Garbage collection

GC finds objects that are not reachable from GC roots and reclaims them. Roots include local references in live frames, static fields, JNI global refs, and a few VM-internal handles. Reachability is graph reachability, not "I still have a pointer I forgot about in a cache".

Young / old, STW vs concurrent

A minor (young) collection is frequent and cheap if most objects are dead. A major or mixed collection visits old regions. Stop-the-world means mutator threads pause at safepoints. Concurrent collectors do most marking and copying beside the app, but still take short STW pauses for roots or to flip spaces. "Concurrent" is not "pause-free".

finalize vs Cleaner; reference types

A WeakHashMap is weak on keys, not values. If the value points back at the key, you have accidentally made the key strongly reachable.

GC roots you must name

• Local variables and operand-stack slots of running frames.
• Static fields of loaded classes.
• JNI global references and critical/pinned regions.
• Running-thread objects themselves and their monitors.
• Objects held by the VM (interned strings historically; class objects).

equals, hashCode, toString, clone, compareTo

These methods are contracts, not decorations. Break them and HashMap, HashSet and TreeMap silently lose entries.

equals and hashCode

equals must be reflexive, symmetric, transitive, consistent, and x.equals(null) is false. If a.equals(b) then a.hashCode() == b.hashCode(). The converse is not required (collisions happen). Do not use mutable fields that can change while the object is a map key. Prefer Objects.equals and Objects.hash (or a cached hash on immutable objects).

== compares references (and primitives). equals compares values if you overrode it. For String, always equals unless you are talking interned identity.

toString, clone, compareTo

toString is for humans and logs. It must not throw and should not be enormous. clone is a broken pattern: Cloneable is a marker, Object.clone is protected and does a field-for-field copy (shallow). Mutable fields are shared. Prefer a copy constructor or a static factory. If you must clone, copy mutable children and document it.

compareTo must be a total order (or you document nulls), consistent with equals if the class is used in SortedSet/SortedMap, and sgn(a.compareTo(b)) == -sgn(b.compareTo(a)). A Comparator that returns 0 for unequal objects will collapse them in a TreeSet.

Immutability, intern, StringBuilder

An immutable class: final class (or careful sealing), all fields private final, no mutators, defensive copies of incoming and outgoing mutable state, and no leaking this from the constructor. String, boxed primitives, and well-written value types qualify.

String is immutable: length, hash and bytes (or coder + value array) do not change. Concatenation with + in a loop allocates many intermediates; use StringBuilder. StringBuffer is the synchronized leftover; do not use it in new code. The compiler and runtime already rewrite a single expression of + into a builder (and, on modern JDKs, invokedynamic concat).

String.intern() returns the canonical pooled instance. The pool lives on the heap (since Java 7, not PermGen). Interning every request string is a leak. == on interned strings is an identity trick; do not write production code that depends on it unless you intern both sides.

String a = new String("hi");
String b = "hi";
a == b;              // false: a is a distinct heap copy
a.intern() == b;     // true: both are the pooled "hi"
Integer x = 80, y = 80;
x == y;              // true: Integer cache, typically -128..127
Integer u = 200, v = 200;
u == v;              // false: not cached; use equals

OOP: access, types, nesting, newer syntax

Java's object model is single class inheritance, multiple interface implementation, and nominal types. Interviews test whether you pick inheritance for genuine "is-a" variation and composition for "has-a" reuse.

Access and inheritance vs composition

*A subclass in another package does not see package-private members. Prefer composition: hold a helper and delegate. Inherit only when you need polymorphism and the Liskov substitution rule holds.

Abstract class vs interface; default and sealed

Default methods let you evolve an interface without breaking existing implementors. They are not a substitute for a shared base class when you need state. Sealed classes and interfaces (newer Java) restrict which types may extend them; useful for exhaustive switch. Mention them; do not pretend every Android min-SDK has them. Records are transparent, final, shallowly immutable carriers with generated equals/hashCode/toString and a canonical constructor. They are not a full domain model.

Nested types

A non-static inner class keeps the outer object alive. A delayed Handler message holding an inner Handler keeps the Activity after onDestroy. Fix: static nested class + WeakReference, or clear callbacks. Details of the Looper sit in Android frameworks.

Generics: erasure, PECS, wildcards, heap pollution

Generics are a compile-time type system. At runtime, a List<String> is a List. The compiler inserts casts. That is erasure. You cannot write new T(), new T[], or list instanceof List<String> in a useful way. You cannot overload two methods that erase to the same signature.

PECS and wildcards

PECS: producer extends, consumer super. If a method only reads Ts from a collection, take Collection<? extends T>. If it only writes Ts in, take Collection<? super T>. If it does both, use Collection<T>.

void putAll(List<? super Integer> dest, List<? extends Integer> src) {
  dest.addAll(src);   // read Integers from src, write into dest
}
// dest can be List<Object> or List<Number>; src can be List<Integer> or List<? extends Integer>

? extends T is a producer: you can get T, you cannot add (except null). ? super T is a consumer: you can add T, you can only get Object.

Reified vs not; heap pollution

Java generics are not reified: the VM does not know T at runtime. Kotlin inline functions with reified are a compiler trick on the JVM, not a Java language feature. Arrays are reified: new String[n] knows its component type, which is why String[] is a subtype of Object[] (covariant arrays) and a store can throw ArrayStoreException.

Heap pollution is when a variable of type List<String> actually contains a Integer because someone used raw types or unchecked casts. The failure is a later ClassCastException, not at the add.

List list = new ArrayList<String>();  // raw
List<String> strings = list;
list.add(42);                          // unchecked, pollutes
String s = strings.get(0);             // ClassCastException here

Vararg methods of generic type (T...) allocate an array of the erased type and are a classic pollution source; the compiler warns. Prefer List<T> over T... for generics.

Collections: implementations, cost, concurrency

The collections framework is interfaces plus implementations. Interviews want complexity, iteration failure modes, and which type is thread-safe. Algorithm patterns (two pointers, heaps) live on Data structures and algorithms; this page is the Java library and its traps.

List, Set, Map at interview depth

ArrayList growth

An empty ArrayList starts with a shared empty array. The first add allocates capacity 10. Later growth is newCap = oldCap + (oldCap >> 1) (one and a half times), not a doubling. Amortized add is still O(1). If you know the size, pass it to the constructor so you do not copy.

HashMap internals (the puzzle they always ask)

Capacity is a power of two. The bin index is (n - 1) & hash, after a mix: h ^ (h >>> 16). Each bin is a linked list until it treeifies: a bin becomes a red-black tree only when the chain length is at least 8 and the table capacity is at least 64. If the chain is long but the table is smaller than 64, HashMap resizes instead of treeifying. Untreeify happens when a tree bin shrinks to 6. Load factor defaults to 0.75. This is why "HashMap is O(1)" is average-case, and why a bad hashCode still hurts until treeify or resize kicks in.

table length n = 16
hash mix: h ^ (h >>> 16)
index = (n-1) & h

bin[i]:  e0 -> e1 -> e2 -> ...   (list)
         if count ≥ 8 and n ≥ 64  -->  red-black tree
         if count ≥ 8 and n < 64  -->  resize table first

Concurrent maps and synchronized wrappers

Fail-fast iterators on ArrayList and HashMap compare a modCount to an expected value. A structural change on another thread (or the same thread, except through Iterator.remove) throws ConcurrentModificationException. It is a best-effort bug detector, not a concurrency protocol.

Exceptions: checked, unchecked, resources

An exception is a signal that a method cannot finish its contract. Java splits the tree at Throwable: Error (the VM is in trouble) and Exception (the program might recover). RuntimeException is an Exception you are not forced to declare. That split is the checked vs unchecked rule.

Throwable
  ├── Error          (OutOfMemoryError, StackOverflowError, NoClassDefFoundError)
  └── Exception
        ├── RuntimeException   (unchecked: NPE, CCE, IAE, ConcurrentModificationException)
        └── other Exception    (checked: IOException, SQLException, InterruptedException)

Checked vs unchecked; Error vs Exception

Checked exceptions are for conditions a reasonable caller can be expected to handle: I/O, parse failures, missing files. Unchecked exceptions are for programming bugs (null, bad index, broken invariants) or for environments that cannot usefully recover at each call site. Error means the VM or linkage is compromised; do not catch OutOfMemoryError and pretend the heap is fine. Exception is the recoverable side of the tree, including both checked types and RuntimeException.

InterruptedException is checked on purpose: it is how a thread is asked to stop waiting. Swallowing it without restoring the interrupt flag (Thread.currentThread().interrupt()) hides cancellation.

try-with-resources and suppressed exceptions

A resource implements AutoCloseable (or Closeable). try-with-resources closes it in reverse order of declaration, even when the body throws. If close() also throws, that exception is suppressed and attached to the primary exception via addSuppressed. Always inspect getSuppressed() when debugging a close failure that "vanished".

try (InputStream in = Files.newInputStream(path);
     OutputStream out = Files.newOutputStream(dest)) {
  in.transferTo(out);
} // close out, then in; suppressed exceptions recorded on the first throw

A manual try/finally that closes in the finally can hide the original exception if close throws; try-with-resources was invented to stop that. Never return from finally (it swallows the in-flight exception and invents a new return). Never throw from finally if you can avoid it.

Concurrency: locks, j.u.c, pools, futures

Several threads, one heap. Without a happens-before edge, a write on thread A need not be visible to thread B, and the compiler and CPU may reorder independent accesses. java.util.concurrent is the library built on that model. This section is the toolkit; the next section is the JMM itself.

synchronized, volatile, wait/notify

synchronized (lock) acquires the monitor, runs the body, then releases. It is reentrant: the same thread may enter again. Entry and exit establish happens-before with the next thread that acquires the same monitor. volatile reads and writes of that field are not reordered with other accesses in ways that break the JMM; a write happens-before a subsequent read of the same variable. volatile does not make i++ atomic.

wait, notify and notifyAll must be called while holding the monitor of the same object. Always wait in a while loop that re-checks the condition (spurious wakeups, and notify-all with several predicates). notify wakes one waiter; notifyAll wakes all, who then contend for the monitor. Prefer Lock/Condition or higher-level latches unless you are implementing a simple monitor.

synchronized (queue) {
  while (queue.isEmpty()) {
    queue.wait();          // releases monitor; reacquires before returning
  }
  return queue.remove();
}

java.util.concurrent toolkit

ThreadPoolExecutor parameters

Core size, max size, keep-alive, work queue, thread factory, and rejected-execution handler. The admission rule: if fewer than core threads, create one; else offer to the queue; if the queue is full and thread count is under max, create; else reject. A LinkedBlockingQueue with no capacity cap means max size is never reached (the queue never fills). A SynchronousQueue hands off to a thread or else grows to max (cached-thread style). AbortPolicy throws; CallerRunsPolicy runs on the submitter (backpressure); DiscardPolicy drops work silently (usually wrong).

submit(task)
  if workers < core      --> start worker
  else if queue.offer    --> sit in queue
  else if workers < max  --> start worker
  else                   --> handler (abort / caller-runs / discard)

Deadlock, livelock, ThreadLocal, CompletableFuture

Deadlock: two or more threads each hold a lock the other needs; nobody makes progress. Fix by lock ordering, try-lock with backoff, or fewer locks. Livelock: threads keep changing state in response to each other and never finish (polite people in a corridor). Starvation: a thread never gets the lock or CPU (unfairness, low priority).

ThreadLocal is a per-thread slot. On a pool, values survive to the next task unless you remove() in a finally. That is a leak of objects and of security context. Android's Looper is stored in a ThreadLocal; that is why Looper.prepare() is per thread.

CompletableFuture is a composable promise: supplyAsync, thenApply, thenCompose (flatMap), thenCombine, exceptionally, whenComplete, orTimeout. State the executor; the common ForkJoin pool is a bad default for blocking I/O. get() blocks and wraps exceptions in ExecutionException. Prefer join() only when you already handle unchecked wrapping, or stay async to the edge.

Java Memory Model: visibility, reorder, finals, DCL

The JMM defines when a write becomes visible and which reorderings are allowed. It is not "the heap layout". Without synchronization, the compiler, JIT and CPU may keep writes in registers, buffer them, or move them, as long as a single thread still sees its own program order (intra-thread semantics).

Happens-before (the edges you must name)

• Program order in one thread: each action happens-before later actions in that thread.
• Monitor unlock happens-before a later lock of the same monitor.
• A volatile write happens-before a later read of that same variable.
• A thread start happens-before the first action in the started thread.
• The last action of a thread happens-before another thread successfully joins it.
• An interrupt happens-before the interrupted thread detects it.
• Happens-before is transitive.
• Default initialization (zeros, nulls) happens-before any action.

A data race is two accesses to the same non-volatile location, at least one a write, not ordered by happens-before. Racy programs have almost no guarantees: you may see stale values, or torn values for long/double on some implementations.

final field safety

If a constructor writes final fields (and does not publish this early), then any thread that sees the object reference after construction sees those final fields initialized. That is why immutable objects can be published through a data race on the reference and still be safe to read. Do not call overridable methods or register listeners in the constructor; that leaks this and voids the guarantee.

Double-checked locking and why volatile is required

class Holder {
  private volatile Expensive inst;   // volatile is required
  Expensive get() {
    Expensive e = inst;              // local read; one volatile load on the fast path
    if (e == null) {
      synchronized (this) {
        e = inst;
        if (e == null) {
          inst = e = new Expensive();
        }
      }
    }
    return e;
  }
}

Without volatile, thread B can see a non-null inst whose constructor writes have not happened-before B's reads: a partially constructed object. The JMM allows the store of the reference to be reordered with stores to the fields. volatile on inst forbids that publication. Initialization-on-demand holder (a static nested class) is simpler for static singletons: class init is already synchronized by the VM.

Streams and Optional: when they hurt

Streams and Optional are library features, not a second language. Interviews punish tutorial dumps ("map, filter, reduce") and reward judgement: allocation, laziness, parallelism and null discipline.

Streams that cost more than they save

• Tiny collections: the pipeline objects, lambdas and boxing dwarf the work. A for-loop is clearer and faster.
• Per-element boxing: Stream<Integer> over primitives; use IntStream or arrays.
• parallel() on a tiny or I/O-bound stream, or on a pool already saturated. Parallel streams use the common ForkJoinPool and can stall unrelated work.
• Side effects in map/filter: order and splitting become undefined; debugging dies.
• Repeated pipelines over the same data when one loop could compute several aggregates.
• Holding a stream: it is single-use; a second terminal operation throws.

Prefer streams when the pipeline is the domain language (filter, group, flat-map nested structures) and the size justifies it. State complexity: a well-written stream is still O(n); it is not free parallelism.

Optional without the religion

Optional is a return type for "value or absent" on a method that would otherwise return null. It is not a field type for every class (allocation, serialization pain). It is not a method parameter (the caller already knows; use overloading or two methods). Never Optional.get() without a guard; use orElse, orElseGet, orElseThrow, ifPresent. orElse(compute()) always computes; orElseGet(this::compute) is lazy. Do not wrap an Optional in another Optional. On Android, Optional is fine on modern ART but still not a Binder type.

Serialization, cloning, defensive copies

Java serialization (Serializable, ObjectOutputStream) is a hidden public constructor. It bypasses your constructors, participates in gadget attacks when the classpath is hostile, and is a poor IPC format. On Android, prefer Parcelable for Binder and a versioned explicit format (protobuf, JSON you control) for disk. See Binder and AIDL for Parcel rules.

Serialization pitfalls

• serialVersionUID: if you do not set it, the compiler's default changes when you add a field; old bytes fail. Set it and document compatible changes.
• Insecure defaults: deserializing untrusted bytes can call unexpected constructors via readObject gadgets. Do not deserialize from the network without a filter (JEP 290) and a tight allow-list.
• No constructor: invariants in constructors do not run. Implement readObject and re-validate; consider the serialization proxy pattern (write a dedicated DTO, read it back into a real object).
• Transient fields are skipped; you must restore them or document defaults.
• Inheritance: a non-serializable superclass needs an accessible no-arg constructor or deserialization fails.
• Not for Binder: reflection, temporary objects, huge graphs. Use Parcelable.

Cloning vs defensive copies

Object.clone is a field-for-field bitwise copy of the object header's payload. Nested mutable objects are shared. A copy constructor or builder copies what you name. Defensive copies: copy mutable arguments on the way in and mutable internals on the way out so callers cannot break immutability. If you store a Date or an array, copy it. Unmodifiable wrappers (List.copyOf, Collections.unmodifiableList) still share the backing store unless you copy first.

public Period(Date start, Date end) {
  this.start = new Date(start.getTime());
  this.end = new Date(end.getTime());
  if (this.start.after(this.end)) throw new IllegalArgumentException();
}
public Date start() { return new Date(start.getTime()); }

JNI from the Java side

A native method has no Java body. The VM looks up a C function when the class is linked (or when you register it). You load the library that contains that function with System.loadLibrary("foo"), which maps libfoo.so on Android/Linux (the lib prefix and .so suffix are added). Static initializers of the class that declares the natives are the usual place to load, so the first use cannot race a missing library.

public final class Crypto {
  static { System.loadLibrary("crypto_jni"); }
  public static native byte[] sha256(byte[] in);
}
// C side (not shown): JNIEXPORT jbyteArray JNICALL
// Java_com_example_Crypto_sha256(JNIEnv*, jclass, jbyteArray);

What Java-side interviews expect

• Declaration: native, no body; can be static or instance. Overloads get extra name mangling (signatures in the symbol).
• Load: loadLibrary vs load(absolutePath). Failure is UnsatisfiedLinkError at load or at first call if the symbol is missing.
• RegisterNatives: the C side can bind function pointers; useful for obfuscation and for avoiding exported symbols. Java still just calls the native method.
• Types: primitives map directly; objects are opaque handles. Arrays and strings are objects. You do not dereference them in Java as C pointers.
• Exceptions: a native method may throw (the C side calls Throw); Java sees a normal exception. Pending JNI exceptions must be cleared on the C side before further JNI calls.
• Threads: a Java thread that calls native is the same OS thread. Native code that calls back into Java must attach if it is not already a Java thread.

ART's moving GC means a raw pointer obtained in C to a Java array is only valid in a critical/pin region or after a copy. That is why the C page matters on Android even when your Java looks correct. C++ JNI wrappers are a different language layer; see C++ if the native side is C++.

Android Java: ART, dex, Binder types, the main thread

This is Java as it actually runs on a phone. It is not a second copy of AMS, WMS or Zygote service lists; those live on Android frameworks. IPC machinery lives on Binder and AIDL. Here: the runtime, the file formats, the types that cross Binder, and why the UI thread may not block.

ART and dex / odex / vdex

The APK carries dex (Dalvik executable): a register-based bytecode derived from Java bytecode via d8/r8. vdex stores verified dex so verification is not repeated. odex / oat is the AOT output of dex2oat (native code plus metadata). A .art image is a pre-initialized heap of classes (boot image, sometimes app images) that Zygote maps. Compiler filters (verify, quicken, speed, speed-profile) trade install time, disk and CPU for runtime speed. JIT still compiles hot methods; profiles from production guide the next dexopt. First boot after OTA is slower because dexopt reruns; see frameworks for PMS/installd.

.java / .kt --> javac/kotlinc --> .class --> d8/r8 --> classes.dex (in APK)
                                                      │
install / idle / profile  --dex2oat-->  .vdex (verified) + .odex/.oat (compiled)
Zygote maps boot .art image; app process inherits it copy-on-write

Handler and Looper (brief)

The main thread is not a busy loop of your code. ActivityThread.main prepares a main Looper and calls Looper.loop(), which blocks in epoll until a Message is due, then dispatches to a Handler. Any thread may post; only the Looper thread runs the callback. Incoming Binder calls run on the Binder pool, not on that Looper. Full queue, sync barriers and Choreographer: Android frameworks.

Boxed types on Binder; Parcelable vs Serializable

AIDL and Parcel prefer primitives, String, arrays, List/Map of supported types, other Binders, file descriptors, and Parcelable. A boxed Integer or Boolean is an object: it can be null, it allocates on both sides, and it is easy to confuse with a primitive default. A primitive boolean cannot express "unset"; a boxed Boolean can, and then the receiver NPEs on auto-unbox. Do not send boxed types in a hot Binder path. Parcelable is explicit flatten/unflatten, no reflection, intended for IPC. Serializable is slow, reflective, and not a Binder-friendly format. Parcel is not a disk format.

Why the main thread cannot block

Input, lifecycle, traversals and most component callbacks are messages on the main Looper. If one message runs too long (disk, network, a synchronous Binder call to a stuck service, a lock held by a background thread doing I/O), later messages miss their deadlines. Typical ANR timeouts: input about 5 s, broadcast 10 s, service 20 s. The idle Looper.loop itself is asleep in the kernel and is not an ANR. Move work off the main thread; post results back with a Handler. Do not recopy AMS/WMS here.

Common interview puzzles

These are the short items that decide a screening loop. Each one has a one-line trap and a precise fix. If you only revise one section the night before, use this plus quick revision.

Pass-by-value of references

void clear(List<String> xs) { xs.clear(); }      // caller sees empty list
void rebind(List<String> xs) { xs = new ArrayList<>(); }  // caller unchanged
void swap(Integer a, Integer b) { /* cannot swap caller vars; Integer is immutable anyway */ }

Java never has C++-style reference parameters. Reassigning a parameter does nothing to the caller. Mutating the object does. Primitives are copied. This is the same rule as in DSA whiteboard code when you pass an array: the array object is shared; the variable is not.

try / finally / return

int f() {
  try { return 1; }
  finally { return 2; }   // f() is 2; the 1 is discarded
}
int g() {
  try { throw new RuntimeException("x"); }
  finally { return 0; }   // exception is swallowed; g() is 0
}

Overload vs override

Which overload runs is chosen at compile time from the static types of the arguments. Which override runs is chosen at runtime from the dynamic type of the receiver. A method is an override only if the signature matches (after erasure) and you intended it; @Override is mandatory in serious code. Return types may be covariant. Private, static and constructors are never overridden (static hides).

Quick revision

• Java is the language; HotSpot is a JVM; ART is Android's runtime. Kotlin compiles to the same bytecode family; this page is Java.
• javac emits class files (bytecode + constant pool), not machine code. ART's on-disk code is dex, then oat/vdex via dex2oat.
• A class is (binary name, defining loader). Parent delegation asks the parent first so core types cannot be spoofed.
• Initialization order: superclass statics, this statics, superclass instance + ctor, this instance + ctor. Compile-time constants do not trigger init.
• Stack holds frames (primitives and references). Heap holds objects. Class metadata is Metaspace / ART native, not PermGen.
• Object header: mark word + class pointer (+ array length). Compressed oops and compressed class pointers are optional 32-bit packs.
• HotSpot: young/old (G1 regions). ART: Concurrent Copying, moving, Zygote image space kept stable for copy-on-write.
• Escape analysis may scalar-replace a non-escaping new; do not claim every allocation hits the heap.
• GC roots: locals, statics, JNI globals, thread/monitor internals. Weak / soft / phantom are not roots in the strong sense.
• STW pauses mutators; concurrent GC still has short safepoint pauses. finalize is obsolete; use Cleaner.
• equals is reflexive, symmetric, transitive, consistent, false for null. Equal objects must share a hashCode.
• Never mutate a key while it sits in a hash map. Prefer immutable keys.
• String is immutable; intern is a heap pool; do not intern unbounded input. StringBuilder for loops; skip StringBuffer.
• Integer cache is typically −128..127. == on boxed integers outside that range is a bug.
• clone is shallow; prefer a copy constructor. compareTo must agree with equals in sorted collections.
• Composition over inheritance unless Liskov holds. Default methods evolve interfaces; they do not add instance fields.
• Inner and anonymous classes hold this$0. Static nested + WeakReference for Android Handlers.
• Records and sealed types are newer Java; mention them, do not assume every Android API level has them.
• Generics erase. PECS: producer extends, consumer super. Heap pollution shows up later as ClassCastException.
• Arrays are reified and covariant; generic lists are invariant and erased.
• ArrayList grows about 1.5×; first add uses capacity 10. Prefer ArrayDeque over Stack/LinkedList for queues.
• HashMap treeifies a bin at chain 8 only if table capacity is at least 64; otherwise it resizes.
• HashMap is not thread-safe. Hashtable is coarse synchronized. ConcurrentHashMap is the concurrent map; no nulls.
• Fail-fast iterators use modCount. CHM iterators are weakly consistent.
• Checked exceptions must be declared or caught. Error is for the VM. Do not swallow InterruptedException.
• try-with-resources closes in reverse and records suppressed exceptions. A return in finally discards the pending throw or return.
• Happens-before: program order, unlock/lock, volatile write/read, start, join. A data race has almost no guarantees.
• volatile is visibility and ordering of that field, not atomic i++. DCL requires volatile on the instance field.
• final fields are safely published after construction if you do not leak this.
• wait only inside the monitor, always in a while that re-checks the condition.
• Latch = one-shot N-to-zero. Barrier = reusable "all arrive". Semaphore = permits. Lock + Condition = multiple wait-sets.
• ThreadPoolExecutor: core, then queue, then max, then reject. An unbounded queue means max is never used.
• Deadlock: circular lock wait. Livelock: busy yielding. Always ThreadLocal.remove on pooled threads.
• CompletableFuture: compose with thenCompose; do not block the common pool with I/O.
• Streams hurt on tiny data, boxed primitives, parallel() on the common pool, and side-effecting map/filter.
• Optional is a return type, not a field or parameter. orElse(x) is eager; orElseGet is lazy.
• Java serialization skips constructors and is a security hazard. On Android IPC use Parcelable, never Parcel-on-disk.
• Defensive-copy mutable args and returns. Unmodifiable wrappers still share the backing list unless you copy.
• native + System.loadLibrary on the Java side; C-side JNI is C language.
• ART: dex in the APK, vdex verified, oat/odex compiled. Main thread is a Looper; block it and you ANR.
• Binder calls run on the Binder pool. Boxed Boolean/Integer on Binder allocate and can be null.
• Java is pass-by-value of the reference. Rebinding a parameter does not change the caller; mutating the object does.
• Overload = compile-time, static types. Override = runtime, receiver type. Thread.start creates a thread; run does not.
• String == is identity. Use equals unless both sides are interned by you on purpose.

Glossary

AOT

Ahead-of-time compilation to native code (dex2oat on Android, jaotc/Graal on some JVMs) before or during install, not only at first execution.

ART

Android Runtime: the VM that executes dex-derived code, with its own GC (Concurrent Copying on modern releases), JIT and profile-guided AOT.

Bytecode

The stack-machine instructions in a class file (or the register-machine instructions in dex). Not CPU machine code until a JIT or AOT compiler emits it.

CAS

Compare-and-swap: an atomic hardware update used by java.util.concurrent.atomic and ConcurrentHashMap.

Checked exception

An Exception that is not a RuntimeException; the compiler requires throws or a catch.

Class file

The binary javac emits: header, constant pool, fields, methods and bytecode.

Classloader

The object that locates bytes and defines a Class. Identity of a class includes its defining loader.

Cleaner

A post-mortem cleanup facility built on phantom reachability; the replacement for finalize.

Compressed oops

HotSpot packing of heap references into 32 bits when the heap is within a limited range (typically under ~32 GB).

Concurrent Copying (CC)

ART's moving collector: bump allocation, concurrent mark and copy, short STW root pauses.

ConcurrentHashMap

A thread-safe hash map using CAS and per-bin coordination; null keys and values are forbidden.

Condition

A wait-set attached to a Lock, analogue of wait/notify with multiple named queues.

Constant pool

The class-file table of literals and symbolic references that bytecode indexes.

CountDownLatch

A one-shot synchronizer that blocks until a count reaches zero.

CyclicBarrier

A reusable barrier: N parties must await before any proceeds; optional barrier action.

Dalvik / dex

Dex is the APK bytecode format (historically Dalvik). Modern devices run it on ART, not the old Dalvik VM.

Data race

Conflicting accesses to a non-volatile location with no happens-before order; the JMM gives almost no guarantees.

Default method

An interface method with a body, used to evolve APIs without breaking existing implementors.

Defensive copy

A copy of mutable state taken on the way in or out so callers cannot mutate your internals.

Double-checked locking

A lazy-init pattern that checks a reference outside and inside a lock; the reference field must be volatile.

Eden

The HotSpot young-generation space where most new objects are allocated before a minor GC.

Erasure

The compile-time-only nature of Java generics: List<String> is a raw List at runtime.

Escape analysis

A JIT analysis that may allocate an object on the stack or in registers if it never escapes the method or thread.

ExecutorService

An API to submit tasks to a thread pool and obtain Futures, instead of constructing Threads by hand.

Fail-fast iterator

An iterator that throws ConcurrentModificationException if it sees a modCount change it did not make.

Final-field safety

The JMM guarantee that a fully constructed object's final fields are visible to other threads that see the reference, if this was not leaked.

Finalize

An obsolete Object method queued for a finalizer thread; unpredictable, can resurrect objects; do not use.

ForkJoinPool

A work-stealing pool for divide-and-conquer tasks; hosts the common pool used by parallel streams.

GC root

A reference the collector starts from: locals, statics, JNI globals, and certain VM handles.

G1

Garbage-First, HotSpot's default region-based collector since Java 9.

Happens-before

The JMM partial order that defines visibility and ordering between actions in different threads.

HashMap treeify

Conversion of a long collision chain into a red-black tree when length ≥ 8 and table capacity ≥ 64.

Heap pollution

A generic variable whose runtime contents violate its static type, usually via raw types; fails later on a cast.

HotSpot

The usual desktop and server JVM: classloading, C1/C2 JIT, Metaspace, and a choice of collectors.

Intern pool

The set of canonical String instances returned by literals and String.intern(); on the heap since Java 7.

JIT

Just-in-time compilation of hot bytecode to native code at run time (HotSpot C1/C2; ART JIT).

JNI

Java Native Interface: native methods on the Java side and a C API on the other; see C language.

JMM

Java Memory Model: the language rules for visibility, atomicity of volatiles, and allowed reorderings.

JVM

The virtual machine specified by the Java Virtual Machine Specification; HotSpot is one implementation.

Metaspace

Native memory where HotSpot stores class metadata after the removal of PermGen in Java 8.

Monitor

The intrinsic lock associated with every Java object; used by synchronized, wait and notify.

oat / odex

ART's compiled native code and metadata produced by dex2oat from dex.

Optional

A container for a value that may be absent; intended as a method return type, not a field or parameter.

Parent delegation

The classloader rule: ask the parent loader before defining a class yourself.

Parcelable

Android's explicit flatten protocol for Binder and Intents; not Java serialization and not a disk format.

PECS

Producer Extends, Consumer Super: the wildcard rule for generic APIs.

PermGen

The old HotSpot space for class metadata, removed in Java 8; do not use it as an ART story.

Phantom reference

A reference that does not keep the object alive and whose get is always null; used for cleanup after death.

Record

A transparent, final, shallowly immutable Java class with generated accessors and equality.

ReentrantLock

An explicit lock in java.util.concurrent that the same thread may acquire again; supports fairness and conditions.

Safepoint

A point where the VM can stop a thread for GC or other VM operations.

Sealed type

A class or interface that permits only a listed set of subtypes (newer Java).

Semaphore

A counter of permits used to bound concurrent access to a resource.

Soft reference

A reference cleared under memory pressure, used for caches that should yield to the collector.

STW

Stop-the-world: mutator threads paused at safepoints for a GC phase.

ThreadLocal

A per-thread variable; must be removed on pooled threads or it leaks across tasks.

vdex

Verified dex: ART's cache of verification results so boot and load do not re-verify every time.

Volatile

A field modifier that inserts happens-before between a write and a later read of that field, and forbids certain reorderings.

Weak reference

A reference that does not prevent collection; cleared when the object is no longer strongly reachable.

Work stealing

Idle ForkJoin workers take tasks from other workers' deques; the scheduling model of ForkJoinPool.

Zygote

The warm ART process that preloads classes and forks app processes so they share memory copy-on-write.

Interview questions