Java

Java is a high-level, object-oriented, general-purpose programming language designed to be portable, secure, and robust. Its core promise is: write once, run anywhere (WORA), meaning compiled Java bytecode can run on any system with a compatible JVM (Java Virtual Machine).

When you compile Java source code (.java), the compiler (javac) produces bytecode (.class). That bytecode is not tied to one operating system or CPU architecture. Any platform with a compatible JVM can execute it.

• JVM: Executes Java bytecode.
• JRE: JVM + core libraries needed to run Java apps.
• JDK: JRE + development tools (compiler, debugger, javadoc, etc.) needed to build Java apps.

If you develop Java, install JDK.

Flow:

1. Write source code (.java)
2. Compile with javac into bytecode (.class)
3. Run with java command
4. JVM loads classes, verifies bytecode, interprets/JIT-compiles, then executes

Bytecode is an intermediate instruction set generated from Java source. It is designed for JVM execution, enabling platform portability.

JIT (Just-In-Time) compiler translates hot bytecode paths into native machine code at runtime. This improves performance significantly compared to pure interpretation.

Both. Java is compiled to bytecode, then interpreted/JIT-compiled by JVM at runtime.

A class is a blueprint for creating objects. It defines fields (state) and methods (behavior).

An object is a runtime instance of a class with its own state and behavior.

The standard entry point for standalone Java apps: public static void main(String[] args) JVM starts execution there (for simple app entry).

Every variable has a declared type, and type correctness is checked at compile time (and partly runtime). This reduces many categories of bugs early.

byte, short, int, long, float, double, char, boolean They are not objects; they store raw values directly.

• Primitive: stores actual value.
• Reference: stores memory reference to object.

Objects live on heap; references point to them.

Object forms of primitives: Integer, Long, Double, Boolean, Character, etc. Useful for collections/generics (which require reference types).

• Autoboxing: primitive -> wrapper automatically
• Unboxing: wrapper -> primitive automatically

Convenient but can introduce NullPointerException if wrapper is null.

A named storage location with a type and value/reference.

Scope is the region where a variable/member is accessible:

• local scope
• method parameter scope
• instance field scope
• class (static) scope

• Instance members belong to object instances.
• Static members belong to the class itself (shared across instances).

Multiple methods with same name but different parameter lists in same class.

Subclass provides a new implementation of inherited method with same signature.

A special method used to initialize new objects. It has same name as class and no return type.

If you define no constructor, Java provides a default no-arg constructor. If you define any constructor, default is not auto-generated.

Reference to current object. Used to disambiguate fields, call other constructors (this(...)), and pass current instance.

Reference to parent class. Used to call parent constructor (super(...)) or parent methods/fields.

Bundling data and methods together and restricting direct access to internal state (usually via private fields + public methods).

They provide controlled access, validation, and future flexibility without exposing internals directly.

• public: accessible everywhere
• protected: package + subclasses
• (default/package-private): package only
• private: class only

A namespace to organize related classes and avoid name conflicts.

Convention (reverse domain, e.g., com.example.app) avoids collisions and improves clarity.

A contract specifying methods (and constants/default/static methods) without typical instance state. Classes implement interfaces.

Class can hold state + implementation. Interface defines behavior contract; supports multiple implementation inheritance.

Hiding complex implementation details and exposing essential behavior.

Mechanism where subclass acquires fields/methods from superclass using extends.

Overuse leads to tight coupling and fragile hierarchies. Prefer composition when "is-a" relationship is weak.

Building classes from other classes as fields ("has-a" relationship), often more flexible than inheritance.

Same interface/method call can behave differently depending on actual object type at runtime.

• Compile-time: overloading
• Runtime: overriding + dynamic dispatch

At runtime JVM chooses overridden method based on actual object type, not reference type.

• final variable: cannot be reassigned
• final method: cannot be overridden
• final class: cannot be extended

String is an immutable class representing text.

Security, thread safety, caching/interning efficiency, predictable behavior.

• String: immutable
• StringBuilder: mutable, not synchronized (faster single-thread)
• StringBuffer: mutable, synchronized (legacy thread-safe)

JVM optimization storing interned string literals to reuse objects and reduce memory.

• == compares references
• equals() compares logical content (if overridden accordingly)

Supports hash-based collections (HashMap, HashSet). Equal objects must have equal hash codes.

Collection correctness depends on their contract. Overriding one without the other breaks map/set behavior.

Fixed-size indexed collection of same type elements.

• Array: fixed size, lower-level
• ArrayList: resizable collection with richer API

An event representing an error or unusual condition disrupting normal flow.

• Checked: must be handled/declared (IOException)
• Unchecked: subclasses of RuntimeException, optional handling (NullPointerException)

• try: risky code
• catch: handle exception
• finally: always executes (cleanup)

Automatic resource management for AutoCloseable resources (files, streams, DB connections).

Thrown when dereferencing null reference. Common and important to prevent via validations and design.

Standard set of interfaces/classes for data structures and algorithms (List, Set, Map, Queue, etc.).

• List: ordered, duplicates allowed
• Set: unique elements
• Map: key-value pairs

Type-parameter mechanism for compile-time type safety and reuse (e.g., List<String>).

Avoid manual casting, catch type errors early, improve readability/API design.

Simplified iteration syntax for arrays/iterables: for (Type x : collection) { ... }

Type-safe set of named constants, can include fields/methods/constructors.

Better type safety, expressiveness, and behavior encapsulation.

Defines how threads interact through memory and what visibility/order guarantees exist. Critical for correct concurrent programming.

• Stack: method frames, local variables, call flow (per thread)
• Heap: objects/arrays shared across threads

Automatic memory reclamation for objects no longer reachable from GC roots.

Logical leaks: objects remain reachable unintentionally (static collections, listeners, caches).

Reference strengths influence GC behavior:

• Strong: normal references, prevent collection
• Weak: collectible on next GC if no strong refs
• Soft: collectible under memory pressure
• Phantom: post-mortem cleanup tracking

Immutable objects cannot change after creation. Benefits: thread safety, simpler reasoning, safer sharing/caching.

• class final (or no mutating subclassing risk)
• private final fields
• no setters
• defensive copies for mutable fields
• fully initialize in constructor

Creating a copy of mutable input/output objects to protect encapsulation.

Method returning instance instead of public constructor (e.g., of(), valueOf(), getInstance()).

Naming clarity, instance caching/reuse, subtype return flexibility, controlled creation logic.

Constructs complex objects step-by-step, especially with many optional parameters.

Many constructor parameters hurt readability and cause argument-order mistakes.

Providing dependencies from outside class rather than creating them internally. Improves testability and modularity.

General principle where framework/container controls object lifecycle and wiring.

Five OO design principles: S, O, L, I, D for maintainable/extensible software.

A class should have one reason to change (one core responsibility).

Software entities should be open for extension, closed for modification.

Subtypes must be substitutable for base types without breaking correctness.

Prefer small, focused interfaces over fat interfaces forcing irrelevant methods.

Depend on abstractions, not concretions.

• Coupling: dependency between modules (lower is better)
• Cohesion: how focused a module is internally (higher is better)

Approximate growth rate of algorithm runtime/memory as input size grows.

Examples:

• ArrayList get by index: O(1)
• ArrayList insert middle: O(n)
• HashMap average get/put: O(1)
• TreeMap get/put: O(log n)

• HashMap: hash-based, unordered (fast average O(1))
• TreeMap: red-black tree, sorted keys (O(log n))

Frequent insertion/removal at ends/known node positions. Often slower random access than ArrayList.

• Queue: FIFO
• Deque: double-ended queue (insert/remove both ends)

Queue ordered by priority (natural/comparator), not insertion order.

External strategy for custom object ordering.

• Comparable: natural ordering inside class
• Comparator: custom ordering outside class

Iterator detecting concurrent structural modifications and throwing ConcurrentModificationException (best-effort).

Executing multiple tasks overlapping in time (parallel or interleaved).

• Process: independent memory space
• Thread: lightweight execution unit within process sharing memory

• Extend Thread
• Implement Runnable
• Prefer executor framework (ExecutorService) in real apps

Pooling, lifecycle management, task queueing, better resource control and scalability.

Mechanism ensuring mutual exclusion and memory visibility across threads.

• Mutual exclusion on monitor lock
• Happens-before visibility on lock release/acquire

Incorrect behavior due to unsafely shared mutable state timing between threads.

Two/more threads waiting indefinitely for each other’s locks/resources.

Threads keep reacting to each other but make no progress.

Thread never gets sufficient CPU/resource due to scheduling/priority unfairness.

Ensures visibility of variable updates across threads and prevents certain reorderings. Not a substitute for atomic compound actions.

Classes like AtomicInteger provide lock-free thread-safe atomic operations.

Atomic CPU-assisted primitive used for non-blocking concurrency updates.

Explicit lock with features beyond synchronized (tryLock, fair policy, interruptible lock wait).

Allows multiple readers concurrently, but writes are exclusive.

Thread-safe map optimized for concurrent access with high throughput.

Queue where producers/consumers can block when full/empty; useful in producer-consumer patterns.

Represents pending asynchronous computation result.

Advanced async composition API for non-blocking pipelines and callbacks.

Depends on workload:

• CPU-bound: near number of cores
• IO-bound: often larger due to waiting time

Measure and tune empirically.

Declarative processing pipeline for collections/data sources (map/filter/reduce/collect).

Collection stores data; Stream processes data flow (often lazily) and is typically one-time-use.

Intermediate operations are deferred until terminal operation runs.

• Intermediate: map, filter, flatMap, sorted, distinct
• Terminal: collect, reduce, forEach, count, findFirst

Container object representing presence/absence of non-null value to model optionality explicitly.

Generally discouraged for entity fields/serialization boundaries; best for return types.

Shorthand for lambda calling existing method: String::trim, System.out::println

Interface with single abstract method (SAM), target for lambdas.

Function<T,R>, Consumer<T>, Supplier<T>, Predicate<T>, UnaryOperator<T>

Method with implementation inside interface (introduced to evolve APIs compatibly).

Utility-like method inside interface namespace.

Converting object state into byte stream for storage/transfer (native or custom formats).

Security risks, versioning complexity, brittle long-term compatibility. Often prefer JSON/Protobuf/etc.

Runtime inspection/manipulation of classes, methods, fields, annotations.

Pros: flexibility/framework power. Cons: performance overhead, reduced type safety, harder maintenance/security concerns.

Metadata attached to code elements used by compiler/tools/runtime frameworks.

Encourages explicit handling but can add boilerplate and API friction if overused.

Java Platform Module System (module-info.java) for strong encapsulation and reliable configuration.

Better dependency boundaries, smaller runtime images, explicit exports/requirements.

Concise syntax for immutable data carriers with auto-generated equals/hashCode/toString and accessors.

Formal JMM rule establishing visibility/order guarantees between actions. If A happens-before B, effects of A are visible to B.

• Program order within a thread
• Unlock happens-before subsequent lock of same monitor
• Write to volatile happens-before subsequent read of same variable
• Thread start/join relationships

Compilers/CPUs reorder instructions for optimization. Without proper synchronization, other threads may observe surprising states.

Before JMM fixes and proper volatile, object publication could expose partially constructed state. Modern form requires volatile on instance field.

Ensuring object reference and fully constructed state become visible to other threads correctly.

• static initializers
• volatile references
• final fields + no escape during construction
• synchronized handoff
• concurrent collections

Properly constructed objects guarantee visibility of final field values across threads after publication.

Independent variables on same CPU cache line causing contention and performance degradation between threads.

Multiple threads competing for same lock, increasing wait time and reducing throughput.

• Coarse: simpler, less concurrency
• Fine: more parallelism, higher complexity/risk

Using multiple locks for different data segments to reduce contention.

Advanced lock supporting optimistic reads + read/write modes for specific high-read scenarios.

Parallel execution framework using work-stealing for divide-and-conquer tasks.

Useful for CPU-bound large datasets with stateless operations. Avoid blindly in IO-bound/small-data/shared-resource-sensitive paths.

• Non-thread-safe side effects
• Poor splitting characteristics
• Overhead > benefit
• Contention on shared collectors

Mechanism to prevent fast producers from overwhelming slower consumers.

Reactive Streams interfaces (Publisher/Subscriber/Subscription) define demand signaling.

Non-blocking IO APIs with channels, buffers, selectors for scalable IO patterns.

• Blocking: thread waits per operation
• Non-blocking: operations can return immediately; multiplex events

Allow one/few threads to monitor many channels for readiness events.

File region mapped into memory space for potentially faster random access IO.

Position, limit, capacity, mark; correct flipping/clearing is crucial.

Component loading class bytecode into runtime. Supports namespaces and dynamic loading.

Class loader asks parent first before loading class itself, ensuring core classes consistency/security.

• Classpath: traditional dependency location
• Module path: JPMS module resolution with stronger boundaries

Native memory area storing class metadata (replaced PermGen in Java 8).

Excessive class generation/loading or classloader leaks prevent metadata reclamation.

References keep old classloader reachable (common in app servers/redeployments), causing memory retention.

Young generation (new objects), old generation (long-lived), plus metadata spaces. Optimizes based on object lifetime patterns.

• Minor: collects young gen, frequent/shorter
• Major/Full: old gen/whole heap, less frequent/often longer pauses

Stop-the-world pause temporarily halting application threads during certain GC phases.

• Throughput focus: maximize work done
• Latency focus: minimize pause times

Collector choice depends on SLA.

Region-based collector targeting predictable pause times with concurrent phases.

Measure first (logs/metrics), tune for specific workload goals, avoid random parameter tweaking.

JIT optimization determining object confinement; may allocate on stack or eliminate allocations.

JIT replaces method call with method body to reduce call overhead and enable further optimization.

Highly variable receiver types can reduce optimization potential (devirtualization limits).

Fallback from optimized machine code to interpreter when assumptions fail.

JIT needs execution time to optimize. Early runs may not represent steady-state performance.

Java Microbenchmark Harness avoids common benchmarking mistakes (dead code elimination, warm-up issues, etc.).

JIT optimizations, JVM warm-up, GC noise, constant folding, dead-code elimination can invalidate results.

Classes intended as immutable identity-less values; identity-sensitive operations discouraged.

Transparent immutable data aggregates (DTO-like carriers).

Restrict which classes/interfaces can extend/implement a type. Improves domain modeling and exhaustive reasoning.

Language support to simplify type checks/deconstruction (e.g., pattern matching for instanceof, switch patterns).

They are safer/more expressive (can return values, avoid accidental fall-through with concise syntax).

Multiline string literal syntax improving readability for SQL/JSON/templates.

Lightweight thread managed by JVM enabling large concurrency levels with simpler blocking style code.

Platform threads map closer to OS threads; virtual threads are many-to-few scheduled by JVM, lower resource cost per task.

High-concurrency IO-bound workloads (many waiting tasks). Less benefit for pure CPU-bound tasks.

Treat related concurrent tasks as a unit with managed lifecycle, cancellation, and error propagation.

Clearly define invariants, preconditions, postconditions, exceptions, and thread-safety expectations.

Ability to run previously compiled binaries against newer library versions without recompilation issues.

Source compatibility concerns recompiling source code. Binary compatibility concerns existing compiled artifacts at runtime.

Can break both source and binary compatibility for downstream users.

Communicate compatibility expectations via version numbers and change discipline.

Embedding and namespace-relocating dependencies to avoid version conflicts in distribution artifacts.

Conflicting transitive versions causing runtime/classpath issues.

Use dependency management, BOMs, convergence checks, minimal dependencies, reproducible builds.

Centralized dependency version alignment artifact (common in Maven ecosystems).

Compile-time tools generating code/metadata based on annotations.

Reduces boilerplate, enforces patterns, improves consistency. But overuse can hide complexity.

Compiling before runtime for faster startup/lower footprint trade-offs vs dynamic optimization flexibility.

Alternative JVM/JIT ecosystem with polyglot capabilities and native image compilation options.

Faster startup/lower memory, but limited dynamic features and different optimization/runtime behavior.

Ability to understand system through logs, metrics, traces, profiling, health signals.

Structured logs, correlation IDs, leveled verbosity, no sensitive data leakage, actionable messages.

• Counters
• Gauges
• Histograms/timers

Use them to track throughput, latency, errors, saturation.

Tracking request path across services to diagnose latency and failures end-to-end.

Stops repeated calls to failing dependency, allowing recovery and reducing cascading failures.

Use bounded retries, exponential backoff, jitter, and idempotent operations awareness.

Without proper timeouts, threads/resources can hang, causing cascading system degradation.

Isolate resources per dependency/workload to contain failures.

Operation can be repeated safely with same effect. Essential for retries and at-least-once delivery safety.

In partition scenarios distributed systems choose trade-offs between consistency and availability.

System may be temporarily inconsistent but converges over time.

Detects concurrent updates via version checks instead of holding long locks.

Prevents conflicts by locking data before modification; safer but can reduce concurrency.

Controls visibility/interference between concurrent transactions (read phenomena control).

Not only syntax mastery, but deep understanding of: JMM, concurrency safety, JVM internals, API design, performance measurement, failure handling, maintainability, and production observability.