Java Technical Interview Questions

The JDK develops Java applications, the JRE runs them, and the JVM executes bytecode. The JDK includes development tools such as javac and the JRE. The JRE contains the JVM and runtime libraries. The JVM loads, verifies, and executes Java bytecode while providing portability across operating systems.

HashMap is not thread-safe and permits one null key. ConcurrentHashMap supports concurrent access using fine-grained coordination, does not allow null keys or values, and provides atomic operations such as putIfAbsent.

The garbage collector identifies objects that are no longer reachable from GC roots and reclaims their memory. Modern collectors use generations because most objects become unreachable soon after creation.

An interface defines a contract that multiple unrelated classes can implement. An abstract class provides a shared base with state and implementation. Choose an interface for capabilities and an abstract class for a close family of types.

Java 17 introduced or finalized features including sealed classes, records, pattern matching for instanceof, text blocks, and a modern LTS release baseline.

Object-Oriented Programming organizes software around classes and objects. Objects combine state, represented by fields, with behavior, represented by methods.

The four principles are encapsulation, inheritance, polymorphism, and abstraction. Together they help Java applications remain reusable, maintainable, secure, and extensible.

A class is a blueprint used to create objects. It defines the fields and methods that instances of the class can contain.

An object is an instance of a class. It is created at runtime and contains actual values for the state defined by its class.

A class is a logical blueprint that defines fields and methods. An object is a real runtime instance containing actual values.

Encapsulation wraps data and behavior inside a class and controls access to the data. Private fields with public behavior methods are a common implementation.

Private fields prevent uncontrolled modification. Methods can validate input and preserve the class invariants before changing internal state.

Inheritance allows a child class to reuse and extend the fields and methods of a parent class using the extends keyword.

Inheritance reduces duplicate code, provides a natural relationship between related types, enables extension, and supports runtime polymorphism. It should be used only for a genuine is-a relationship.

Java supports single, multilevel, and hierarchical inheritance through classes. Multiple inheritance of classes is not supported, but a class can implement multiple interfaces.

Multiple class inheritance can create ambiguity when parent classes define the same method, known as the diamond problem. Java avoids this by allowing one direct superclass and multiple interfaces.

Polymorphism means one contract or method name can represent different behavior. Java provides compile-time polymorphism through overloading and runtime polymorphism through overriding.

Compile-time polymorphism is method overloading. The compiler selects the method using the number, types, and order of the arguments.

Runtime polymorphism is method overriding. A parent reference can point to a child object, and Java selects the child implementation at runtime.

Overloading defines methods with the same name but different parameter lists. Changing only the return type is not valid overloading.

Overriding occurs when a child class provides a compatible implementation of an inherited parent method. The child method must respect Java access and return-type rules.

Overloading uses different parameters and is resolved at compile time. Overriding requires inheritance, the same parameters, and is resolved at runtime.

Abstraction hides implementation details and exposes only the operations a caller needs. Java uses abstract classes and interfaces to model abstractions.

An abstract class cannot be instantiated directly. It can contain fields, constructors, concrete methods, and abstract methods that subclasses must implement.

An interface defines a contract. Classes implement it and can implement multiple interfaces, which provides flexible abstraction without multiple class inheritance.

An abstract class can share state, constructors, and implementation with closely related classes. An interface defines a contract that unrelated classes can implement, and a class can implement multiple interfaces.

Yes. Its constructor runs as part of creating a child object and initializes the parent portion of that object.

Yes. Modern Java interfaces can contain default, static, and private methods in addition to abstract methods.

this refers to the current object. It distinguishes fields from parameters, calls current-class methods or constructors, and can pass the current object to another method.

super refers to the immediate parent class. It accesses parent members and calls a parent constructor, which must be the first constructor statement.

Association is a relationship between independent objects, such as a teacher teaching students. Both objects can exist independently.

Aggregation is a weak has-a relationship. The contained object is created outside the container and can continue to exist independently.

Composition is a strong has-a relationship where the container owns the lifecycle of the contained object.

Aggregation allows child objects to exist independently and does not fully control their lifecycle. Composition makes the parent responsible for creating and owning the child objects.

An is-a relationship represents inheritance. For example, Dog extends Animal means a Dog is an Animal.

A has-a relationship represents association, aggregation, or composition. For example, a Car has an Engine when Engine is a field of Car.

Constructor overloading provides multiple ways to create an object by defining constructors with different parameter lists.

No. Constructors are not inherited and belong to their own class. A child constructor can call a parent constructor using super().

Dynamic method dispatch is Java’s runtime mechanism for selecting an overridden method based on the actual object rather than the reference type.

Upcasting assigns a child object to a parent reference. It is safe, automatic, and commonly used for runtime polymorphism.

Downcasting converts a parent reference back to a child reference. It must be checked carefully because an incompatible object causes ClassCastException.

No. Static methods belong to the class. A child declaration with the same signature hides the parent method; the selected method depends on the reference type.

No. Private methods are accessible only inside their declaring class and are not inherited. A same-named child method is independent.

No. A final method cannot be changed by a subclass. Use final when the implementation must remain fixed.

A final class cannot be extended. Java’s String class is a common example.

Loose coupling means depending on abstractions rather than concrete implementations. It improves testing, maintenance, extension, and replacement of dependencies.

Cohesion describes how closely related a class’s responsibilities are. High cohesion means the class has one focused purpose and is easier to test and maintain.

An immutable object cannot change after creation. Use final fields, constructor initialization, no setters, defensive copies, and no exposed mutable state.

Composition avoids unnecessary parent-child coupling and allows implementations to be replaced or tested independently. Use inheritance only when the child truly is a parent type.

Spring Boot uses encapsulated entities and DTOs, service interfaces for abstraction, base types for selective inheritance, polymorphic implementations, and composition through dependency injection.

Define a PaymentStrategy interface, implement credit-card, UPI, and wallet strategies, and inject the selected strategy into a PaymentProcessor. This demonstrates abstraction, polymorphism, composition, and loose coupling.

Create a new class that implements the existing payment interface. The processor remains unchanged, following the Open/Closed Principle.

No. Java supports primitive types such as int, double, char, and boolean, which are not objects. Wrapper classes provide object representations when needed.

Yes. Objects can be obtained through factory methods, reflection, cloning, deserialization, or dependency injection. For example, LocalDate.now() returns an object without application code calling new.

No. Abstract means the class is designed to be extended, while final prevents extension. Using both creates a contradiction and does not compile.

Yes. Private constructors prevent direct creation and are useful for utility classes, singleton implementations, and factory-controlled creation.

Yes. Overloading and overriding are separate. A child can override one overloaded method while inheriting the other overloads.

The four pillars are encapsulation, inheritance, polymorphism, and abstraction.

An interface defines a contract that multiple classes can implement. An abstract class provides shared state or implementation for a closely related class hierarchy.

Private fields protect internal state while public methods expose controlled behavior. This combination supports encapsulation, validation, and maintainability.

Dependency injection supplies abstractions from outside a class, so the class does not construct concrete dependencies. This is a practical way to achieve loose coupling.

State is the data held by an object, such as an employee name. Behavior is the work the object performs through methods, such as calculating salary.

Software entities should be open for extension but closed for modification. Interfaces and polymorphic implementations allow new behavior without changing stable client code.

High cohesion keeps closely related responsibilities together and unrelated responsibilities separate. It produces focused classes that are easier to understand, test, and change.

Keep fields private, expose behavior instead of mutable state, prefer constructor injection, program to interfaces, favor composition, keep classes focused, use immutable objects, and avoid deep inheritance hierarchies.

An exception is an unexpected event that interrupts normal program flow. Java creates an exception object containing its type, message, location, and call sequence.

Exception handling detects runtime problems and responds gracefully using try, catch, finally, throw, and throws.

It prevents sudden termination, provides useful messages, separates error handling from business logic, releases resources, and supports logging and monitoring.

Throwable is the root of Error and Exception. RuntimeException represents unchecked exceptions, while IOException, SQLException, and ClassNotFoundException are common checked exceptions.

Exceptions are usually application-level problems that may be recoverable. Errors normally indicate serious JVM or system failures such as OutOfMemoryError and should rarely be handled.

Checked exceptions are verified by the compiler. The caller must handle them with try-catch or declare them with throws. IOException and SQLException are examples.

Unchecked exceptions extend RuntimeException and are not enforced by the compiler. They commonly represent invalid input, programming errors, or invalid state.

Checked exceptions must be handled or declared and often represent external failures. Unchecked exceptions occur at runtime and commonly represent invalid code, input, or state.

A try block contains code that may throw an exception and must be followed by catch, finally, or both.

A catch block handles an exception thrown by its associated try block and can inspect methods such as getMessage, getCause, and printStackTrace.

finally contains cleanup code that normally runs whether the try succeeds or an exception is caught. Try-with-resources is preferred for closeable resources.

It normally executes, but not after System.exit, an unexpected JVM or operating-system termination, or a fatal process failure.

Yes. A try block may be followed by finally without catch. The exception is still propagated after cleanup.

No. Every catch block must be associated with a try block, otherwise the code does not compile.

Yes. Multiple catch blocks allow different exception types to receive different recovery messages or actions.

Specific exception types must appear before general types. A catch(Exception) before catch(IOException) makes the latter unreachable.

Multi-catch handles unrelated exception types in one catch block when their handling logic is identical. It was introduced in Java 7.

No. Multi-catch alternatives cannot have a parent-child relationship, such as IOException and FileNotFoundException. Use the parent type instead.

throw explicitly creates and raises one exception object, usually when input or a business rule is invalid.

throws declares checked exceptions that a method may pass to its caller. The caller must handle or further declare them.

throw raises an exception object inside code. throws declares exception types in a method signature and can list multiple types.

Exception propagation passes an unhandled exception up the method-call stack until a compatible handler is found or the JVM default handler terminates the thread.

Yes. Both can move through method calls. Checked exceptions must be handled or declared at required boundaries, while unchecked exceptions do not require declaration.

A custom exception is a domain-specific exception created to express a business or application failure clearly.

Extend Exception and declare or handle it at the call site.

Extend RuntimeException. The compiler does not force callers to handle or declare it.

Use them when a caller can reasonably recover from an external condition such as a missing file, failed network connection, or unavailable resource.

Use them for invalid arguments, violated business rules, missing entities, invalid application state, or failures that the current layer cannot meaningfully recover from.

Try-with-resources automatically closes resources implementing AutoCloseable or Closeable after the try block completes.

It reduces boilerplate, prevents resource leaks, closes resources reliably, and handles cleanup exceptions more safely than manual finally code.

Yes. Resources are closed automatically in reverse order of declaration.

AutoCloseable marks a resource that can be closed automatically. Its close method may throw Exception and is invoked by try-with-resources.

If the try body throws and close also throws, the body exception is primary and the close exception is attached as suppressed through getSuppressed().

The return from finally overrides the return from try. Returning from finally is bad practice because it can hide exceptions and results.

An exception from finally can hide an exception from try or catch. Cleanup code should avoid throwing unless there is no safe alternative.

Exception chaining wraps a low-level exception in a higher-level exception while preserving the original cause for debugging.

The cause preserves the original stack trace, root-cause details, and debugging context needed for production diagnosis.

A stack trace shows the exception type and the sequence of method calls, classes, files, and line numbers that led to the failure.

getMessage returns only the exception message. printStackTrace prints the complete call sequence and should normally be replaced by a logging framework in production.

It writes unstructured output directly to standard error, may bypass centralized logging, cannot be controlled by log level, and may expose sensitive details.

final prevents reassignment, overriding, or inheritance. finally provides cleanup flow. finalize is a deprecated cleanup callback and must not be used for resources.

Technically yes, but it also catches serious Errors such as OutOfMemoryError and StackOverflowError. Catch specific exceptions instead.

Technically yes, but catching Error does not guarantee safe recovery. Most Errors represent severe JVM or system failures.

It handles unrelated failures together, hides programming errors, weakens recovery decisions, and makes debugging harder. Catch specific types instead.

Exception swallowing is catching an exception without logging, handling, or rethrowing it. It makes failures invisible and should be avoided.

No. Validate predictable conditions normally and use exceptions for exceptional failures. Frequent exceptions create unnecessary stack traces and obscure intent.

It can throw the same checked exception, a narrower subclass, or none. It cannot throw a broader checked exception than the parent method.

Yes. Unchecked exceptions are not restricted by the checked-exception overriding rules.

Yes. A constructor can throw checked or unchecked exceptions. If it fails, the object is not created successfully.

It can throw unchecked exceptions. A failure during class initialization may be reported as ExceptionInInitializerError.

They can be handled locally, with @ExceptionHandler, globally with @RestControllerAdvice, or translated into custom structured API errors. Centralized handling is preferred for REST APIs.

@ExceptionHandler maps a specified exception to a handler method in a controller or controller advice class.

@ControllerAdvice centralizes shared controller behavior, including exception handlers, across multiple controllers.

@RestControllerAdvice combines controller advice with response-body behavior and is commonly used for global REST API exception handling.

Use a consistent object containing timestamp, status, safe error code, message, path, correlation ID, and validation field errors.

Throw a custom EmployeeNotFoundException from the service, handle it in global advice, and return a safe 404 response with a stable error code.

Handle MethodArgumentNotValidException in global advice, collect field errors, and return a structured 400 or 422 response.

Business exceptions represent known rule violations and usually map to 4xx responses. System exceptions represent technical failures and usually map to 5xx responses.

Generally no. Keep controllers focused on HTTP mapping and let global advice translate service and domain exceptions consistently.

400 represents invalid input, 401 authentication, 403 access denial, 404 missing resources, 409 conflicts, 429 rate limits, 500 unexpected errors, and 503 unavailable dependencies.

Return safe structured errors with status, business code, message, timestamp, path, and correlation ID. Keep stack traces and internal details in secured server logs.

Configure timeouts, classify client errors, retry only transient failures, use circuit breakers, preserve causes, log trace IDs, and avoid exposing downstream internals.

No. Retry transient timeouts or temporary unavailability with bounded exponential backoff. Do not retry validation, authentication, not-found, or non-idempotent failures without protection.

A correlation ID connects logs for one request across gateways, services, databases, Kafka, and downstream calls, making distributed failures traceable.

Classify transient and permanent failures, use bounded retry with backoff, dead-letter topics, idempotent processing, acknowledgements, and monitoring for retry and dead-letter counts.

A dead-letter topic stores messages that still fail after configured retries so the main consumer can continue and operators can investigate or replay them.

A poison-pill message repeatedly fails because of invalid data, schema, or deserialization. It should be isolated after bounded retries instead of blocking the consumer forever.

Translate persistence failures into meaningful application exceptions, log safe context, propagate to global handling, and never expose SQL, credentials, schema details, or vendor messages.

Spring translates vendor-specific database failures into a consistent DataAccessException hierarchy, such as DuplicateKeyException and DataIntegrityViolationException.

By default, Spring rolls back for RuntimeException and Error but not for checked exceptions.

Use @Transactional(rollbackFor = IOException.class) or another explicitly configured exception type.

If a runtime exception is caught and swallowed, Spring may commit the transaction. Rethrow it or explicitly mark rollback when failure should undo the work.

Throw a custom unchecked exception in the service, map it globally, and return a safe 404 Not Found response.

Enforce a database unique constraint, translate DataIntegrityViolationException, and return 409 Conflict. A pre-check alone is unsafe under concurrency.

Configure timeouts, retry safely with backoff, use a circuit breaker, preserve the cause, log correlation details, and return a safe service-unavailable response.

Catch failures at the job boundary, log job and execution IDs, record metrics, isolate item failures when appropriate, retry transient work, and notify support for critical failures.

Observe CompletableFuture or reactive failures with exceptionally, handle, or an equivalent error path. Do not allow asynchronous failures to disappear silently.

Repositories handle persistence details, services enforce business rules, controllers remain thin, global advice maps errors to responses, and logging/monitoring captures technical context.

The exception propagates to the caller. If nobody handles it, the JVM default handler prints details and terminates the affected thread.

The new exception propagates unless another surrounding try-catch handles it. The original handler does not automatically handle failures created inside itself.

Yes, multi-catch can handle unrelated exception types in one block when their handling logic is the same.

Yes. A handler can log and rethrow the same exception or wrap it in a higher-level exception while preserving the cause.

Yes, but it is optional because the compiler does not require unchecked exceptions to be declared. It may still document the method contract.

Yes. An unhandled exception declared by main reaches the JVM default handler and normally terminates the application.

Yes, but excessive nesting makes control flow hard to understand. Prefer focused methods and specific handlers.

Catch specific exceptions, avoid empty catches, preserve causes, use custom domain errors, prefer try-with-resources, avoid finally returns, log safely, centralize REST handling, and distinguish retryable failures.

Usually not at every layer. Add context when wrapping and log once at the boundary that has enough business and technical context.

Include exception and stack trace, correlation and trace IDs, operation, safe business identifiers, downstream service, retry count, and duration. Never log credentials, tokens, or unmasked sensitive data.

Do not return stack traces, SQL, class names, file paths, internal addresses, credentials, tokens, or raw downstream errors. Return a safe structured error instead.