Java & Spring Boot
Complete Notes

Model Answer:

== compares references — it checks if two variables point to the exact same object in memory. For primitive types (int, boolean etc.), == compares values. The .equals() method compares object content. Its default implementation in the Object class uses == (reference comparison), but String, Integer and most other classes override it to compare by value. Critical example: String a = new String("hello"); String b = new String("hello"); a == b is FALSE (different heap objects). a.equals(b) is TRUE (same content). However, String literals use the String Pool: String c = "hello"; String d = "hello"; c == d is TRUE (same pool reference). Rule: always use .equals() for object comparison. Use == only for primitive comparison and reference identity checks. For null-safe comparison: use Objects.equals(a, b) which handles null without NPE.

Model Answer:

HashMap uses an array of "buckets" (default initial capacity 16) combined with linked lists (and Red-Black Trees from Java 8+ when a bucket exceeds 8 entries). On put(key, value): (1) key.hashCode() is called. (2) Hash is further processed: hash ^ (hash >>> 16) to spread bits. (3) Bucket index = hash & (capacity-1). (4) If bucket is empty, create a new Node. (5) If occupied, .equals() checks if the key already exists — update value if yes, add new Node to chain if no — this is a collision. (6) Load Factor (default 0.75): when 75% of buckets are occupied, HashMap resizes — capacity doubles and all entries are rehashed. Java 8 improvement: when a single bucket has more than 8 nodes, the linked list converts to a Red-Black Tree, improving worst-case time from O(n) to O(log n). Always override both hashCode() and equals() together — if two objects are equal, they must have the same hashCode.

Model Answer:

ArrayList uses a dynamic array internally. It gives O(1) random access by index (array indexing), O(1) amortized add at the end, but O(n) for insertion or removal in the middle (elements must shift). Memory: compact, just an array. LinkedList uses a doubly linked list. It gives O(1) add/remove at both ends, O(n) for random access by index (must traverse from head). Memory: each node stores data + two pointers — higher overhead. When to use ArrayList: most cases — random access, mostly reading, appending at end. When to use LinkedList: frequent insertion/deletion at the beginning or middle, implementing a Queue or Deque. In practice, ArrayList outperforms LinkedList in most real scenarios due to CPU cache locality (contiguous memory). Rule of thumb: use ArrayList by default, switch to LinkedList only if profiling shows it is a bottleneck.

Model Answer:

Abstract class: can have abstract and concrete methods, instance variables, constructors, any access modifiers. A class can only extend ONE abstract class. Use when classes share state (instance variables) and some common implementation — IS-A relationship with partial implementation. Example: Vehicle abstract class with common fuel() method but abstract drive() method. Interface: all fields are public static final (constants), all methods are implicitly public. Since Java 8: can have default and static methods. A class can implement MULTIPLE interfaces. Use for capability contracts — what an object CAN DO regardless of its class hierarchy: Serializable, Comparable, Runnable. The key question: IS-A (abstract class) vs CAN-DO (interface). If you have a Dog and a Cat, both ARE-A Animal (abstract class). Both CAN-DO Trainable, Playable (interfaces). Real design tip: prefer interfaces for type definitions — they give more flexibility and support multiple implementation.

Model Answer:

Dependency Injection (DI) is a design pattern where objects receive their dependencies from outside rather than creating them internally. Benefits: decoupling, testability (can inject mock objects for testing), flexibility (change implementation without touching the class). Spring implements DI through its IoC container. Three types: (1) Constructor Injection — dependencies passed via constructor. Best practice — makes dependencies explicit and supports immutability. @Autowired on constructor (optional in Spring 4.3+ if single constructor). (2) Setter Injection — dependencies set via setter methods. Use for optional dependencies. (3) Field Injection — @Autowired directly on field. Convenient but not recommended — hides dependencies, makes testing harder. Spring prefers Constructor Injection. How Spring creates beans: scans @Component, @Service, @Repository, @Controller annotations. When your class has @Autowired, Spring checks its ApplicationContext for a matching bean and injects it. If multiple candidates exist, use @Qualifier("beanName") or @Primary to resolve ambiguity.

Model Answer:

The N+1 problem occurs when fetching a list of entities triggers N additional queries to load their related entities — one query for the parent list plus N queries for the child data. Example: fetch 100 courses (1 query), then access each course's enrollments in a loop — triggers 100 more queries = 101 total queries. This kills database performance. Solutions: (1) JOIN FETCH in JPQL: @Query("SELECT c FROM Course c LEFT JOIN FETCH c.enrollments") — loads everything in ONE query. (2) @EntityGraph: @EntityGraph(attributePaths = {"enrollments"}) on repository method — same effect as JOIN FETCH. (3) Use FetchType.EAGER — loads related entities in the initial query, but avoid this broadly as it can load more data than needed. (4) Batch fetching: @BatchSize(size=25) on the collection — loads children in batches instead of one by one. Detection: enable SQL logging (spring.jpa.show-sql=true) and count queries. Use tools like Hibernate Statistics or p6spy to measure.

Model Answer:

A microservice is a small, independently deployable service that focuses on a single business capability and has its own data store. Monolithic architecture packages all functionality (UI, business logic, data access) into a single deployable unit sharing one database. Key differences: Deployment — in a monolith, any change requires redeploying the entire application (risky for large systems). Microservices deploy each service independently. Scaling — monolith scales all-or-nothing. Microservices scale only the bottleneck service. Fault isolation — a bug in monolith can crash everything. A microservice failure is isolated. Technology — monolith uses one tech stack; each microservice can use the most appropriate technology. Complexity trade-off: monolith is simpler to start with, easier to debug, no distributed systems problems. Microservices introduce network latency, distributed transactions (Saga pattern), service discovery (Eureka), API gateway, distributed tracing (Zipkin). Recommendation: start with a monolith, extract microservices when teams grow and specific services need independent scaling.

Model Answer:

The Singleton pattern ensures a class has only ONE instance and provides a global access point to it. Use cases: database connection pool, logging, configuration manager, caching. Basic implementation problems: simple null check is not thread-safe in multi-threaded environments — two threads can both pass the null check simultaneously and create two instances. Thread-safe solutions: (1) Synchronized method: public static synchronized Singleton getInstance() — works but synchronization on every call is expensive. (2) Double-checked locking with volatile: check null outside synchronized block (fast path), check again inside. The volatile keyword ensures the instance is fully constructed before the reference is published (prevents instruction reordering). (3) Bill Pugh Singleton (best practice): use a static inner holder class — class loading is thread-safe by the JVM. The holder class is not loaded until getInstance() is called: private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } This is the cleanest, most efficient thread-safe singleton implementation.