50 Essential Java Interview Questions: From JVM to Spring Boot Complete Coverage

50 Essential Java Interview Questions: From JVM to Spring Boot Complete Coverage

Introduction

Honestly, I was pretty resistant when I first heard about "Java interview cramming" — who memorizes questions in this day and age? But after interviewing at seven or eight major tech companies, I had an epiphany: these questions aren't about rote memorization, they're about building the skeleton of your knowledge system. I've compiled the 50 most frequently asked Java interview questions, each one I was actually asked in real interviews, covering JVM, Concurrency, Spring, MySQL, Redis, Message Queues, and Distributed Systems. Whether you're a new grad or experienced hire, mastering these will at least get you past the technical round.

1. JVM (8 Questions)

1. What is the JVM memory model?

Heap (Young Generation + Old Generation), Method Area/Metaspace, VM Stack, Native Method Stack, Program Counter. The heap is shared across threads; stacks and counters are thread-private. Interviewers love to follow up: Why split the heap into young and old generations? Because most objects die young — the copying algorithm is efficient for the young generation.

2. What GC algorithms are there?

Mark-Sweep (fragmentation), Mark-Compact (no fragmentation but slow), Copying (used in young gen, fast but wastes space), Generational Collection (combined approach). Must-know follow-up: CMS uses mark-sweep with floating garbage and fragmentation issues; G1 uses region-based mixed collection with predictable pause times.

3. Class loading mechanism and the Parent Delegation Model?

Loading → Verification → Preparation → Resolution → Initialization. Parent Delegation: let the parent classloader load first; only load yourself if the parent can't. Benefits: avoids duplicate loading and security issues. Examples of breaking parent delegation: SPI mechanism (thread context classloader), Tomcat (independent classloader per webapp).

4. When does OOM occur? How to troubleshoot?

Heap overflow (too many objects), Metaspace overflow (too many dynamically generated classes), Stack overflow (recursion too deep). Troubleshooting: jmap for heap memory, jstack for thread stacks, MAT for dump analysis. I was asked in an interview how to handle OOM in production — first add -XX:+HeapDumpOnOutOfMemoryError so you have a dump to analyze when problems occur.

5. What JVM tuning parameters are there?

-Xms/-Xmx for heap size, -Xmn for young gen size, -XX:SurvivorRatio for Eden/Survivor ratio, -XX:MetaspaceSize for metaspace size, -XX:+UseG1GC for garbage collector selection. Practical tuning tip: set -Xms and -Xmx to the same value to avoid dynamic expansion; set G1's MaxGCPauseMillis to 200ms.

6. Differences between strong, soft, weak, and phantom references?

Strong references are never collected, soft references are collected when memory is low (good for caching), weak references are collected on GC (ThreadLocal's key), phantom references only track GC activity. This question seems simple, but interviewers will follow up on ThreadLocal memory leaks — the key is a weak reference that gets collected, but the value is a strong reference that won't, so always call remove() after use.

7. Object creation process in JVM?

Class loading check → Memory allocation (pointer bump or free list) → Zero initialization → Set object header → Execute init method. Concurrency safety uses CAS or TLAB. Follow-up: Object layout in memory? Object header (Mark Word + type pointer), instance data, alignment padding.

8. How to choose a garbage collector?

Single CPU with small memory: Serial. Multi-CPU seeking throughput: Parallel Scavenge + Parallel Old. Low latency: CMS or G1. Large heap with predictable latency: ZGC. Practical experience: JDK8 uses CMS or G1, JDK11+ uses G1 directly, JDK15+ can consider ZGC.

2. Concurrency (10 Questions)

9. Differences between synchronized and ReentrantLock?

synchronized is a keyword, ReentrantLock is an API; synchronized auto-releases the lock, ReentrantLock requires manual unlock; ReentrantLock supports fair locks, interruptibility, and multiple conditions. I was asked: When is ReentrantLock better? Answer: When you need fair queuing, tryLock to avoid deadlocks, or multiple Conditions.

10. What does the volatile keyword do?

Ensures visibility (flush to main memory) and prevents instruction reordering, but doesn't guarantee atomicity. Implemented with memory barriers at the底层. Classic scenario: the instance in DCL singleton pattern must be volatile to prevent other threads from seeing a half-initialized object.

11. Thread pool core parameters and execution flow?

corePoolSize, maximumPoolSize, keepAliveTime, workQueue, threadFactory, rejectedExecutionHandler. Execution flow: core threads first → then queue → then non-core threads → then rejection policy. Four rejection policies: AbortPolicy (throw exception), CallerRunsPolicy (caller executes), DiscardPolicy (discard), DiscardOldestPolicy (discard oldest). Must-know: How to set thread pool parameters? CPU-intensive: N+1, IO-intensive: 2N or calculate by formula.

12. AQS principles?

Core is volatile int state and a CLH bidirectional wait queue. Exclusive mode (ReentrantLock): state 0 means acquirable, state 1 means enqueue and wait. Shared mode (Semaphore): state represents remaining permits. Template method pattern: subclasses implement tryAcquire/tryRelease. I was asked to hand-write a simple AQS in an interview — just extend AQS and override tryAcquire.

13. ThreadLocal principles and memory leaks?

Each Thread object has a ThreadLocalMap where the key is a weak reference to ThreadLocal and the value is a strong reference. Memory leak cause: after ThreadLocal is GC'd, the key becomes null but the value remains. Solution: always call remove() after use. Follow-up: What to watch for when using ThreadLocal in a thread pool? Thread reuse causes data mixing — always remove in finally.

14. What is CAS? What problems does it have?

Compare And Swap, an optimistic locking implementation. Problems: ABA problem (solved with AtomicStampedReference), spin overhead (CPU busy-waiting under heavy contention), can only guarantee atomicity for one shared variable (use AtomicReference to wrap multiple variables).

15. Lock classification in Java?

Pessimistic/Optimistic, Fair/Unfair, Exclusive/Shared, Reentrant/Non-reentrant, Spin/Blocking. synchronized is pessimistic, unfair, exclusive, and reentrant. ReentrantLock defaults to unfair but can be set to fair.

16. Differences between CountDownLatch and CyclicBarrier?

CountDownLatch is one-time, waiting for N threads to complete; CyclicBarrier is reusable, N threads wait for each other to arrive then continue. Scenarios: CountDownLatch for main thread waiting for sub-threads, CyclicBarrier for multi-thread segmented computation with aggregation.

17. Fork/Join framework?

Divide-and-conquer + work-stealing algorithm. Large tasks split into smaller tasks via fork, results merged via join. Work-stealing: idle threads steal tasks from the tail of other threads' queues. Suitable for CPU-intensive recursive computation tasks.

18. Happen-before principles?

Eight rules: program order, volatile, locks, transitivity, thread start, thread termination, thread interruption, object finalization. It's not "happens first in time" but "the result of the previous operation is visible to the subsequent operation."

3. Spring (8 Questions)

19. Understanding of Spring IOC?

Inversion of Control — delegating object creation and dependency management to the container. Implementation: Dependency Injection (DI) including constructor injection, setter injection, and field injection (@Autowired). Bean lifecycle: instantiation → property assignment → initialization → use → destruction. Interviewers love asking: Difference between BeanPostProcessor and BeanFactoryPostProcessor? The former processes Bean instances, the latter processes BeanDefinitions.

20. Spring AOP implementation principles?

JDK dynamic proxy (interfaces) and CGLIB (classes). Spring defaults to JDK proxy when interfaces exist, CGLIB otherwise. SpringBoot 2.x defaults to CGLIB for all. Advice types: Before, After, AfterReturning, AfterThrowing, Around. I was asked: AOP failure scenarios? Internal method calls (not going through proxy), private methods, static methods.

21. Spring transaction propagation mechanisms?

REQUIRED (default, join existing or create new), REQUIRES_NEW (always create new, suspend current), NESTED (nested transaction), SUPPORTS, NOT_SUPPORTED, MANDATORY, NEVER. Most tested: REQUIRED vs REQUIRES_NEW — the former shares the same transaction (rollback together), the latter has an independent inner transaction (inner rollback doesn't affect outer).

22. How does Spring resolve circular dependencies?

Three-level cache: singletonObjects (complete Beans), earlySingletonObjects (early references), singletonFactories (Bean factories). Flow: A creates → discovers dependency on B → B creates → discovers dependency on A → gets A's early reference from third-level cache → B completes → A completes. Note: constructor injection and prototype scope cannot be resolved. Follow-up: Why three levels instead of two? To handle AOP proxies and ensure early and final references are consistent.

23. Differences between @Autowired and @Resource?

@Autowired injects by type (Spring), @Resource injects by name (JSR-250). @Autowired with @Qualifier for name-based injection, @Resource's name attribute specifies the name. Interviewers ask: What if multiple Beans of the same type? Use @Primary or @Qualifier.

24. SpringBoot auto-configuration principles?

@SpringBootApplication includes @EnableAutoConfiguration → SpringFactoriesLoader loads configuration classes from META-INF/spring.factories → filters by @Conditional conditions → assembles Beans. SpringBoot 2.7+ uses META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports instead.

25. Design patterns in Spring?

Factory (BeanFactory), Singleton (Bean default scope), Proxy (AOP), Template Method (JdbcTemplate), Observer (event mechanism), Adapter (HandlerAdapter), Strategy (ResourceLoader). This question demonstrates your depth of understanding of Spring.

26. SpringMVC request processing flow?

Request → DispatcherServlet → HandlerMapping finds Handler → HandlerAdapter executes → Controller processes → returns ModelAndView → ViewResolver resolves view → Response. Follow-up: Difference between interceptors and filters? Interceptors are Spring's, filters are Servlet's; interceptors can access Handler information, filters cannot.

4. MySQL (8 Questions)

27. MySQL index data structure? Why B+ tree?

InnoDB uses B+ tree. Reasons: 1) Short tree (3-4 levels store tens of millions of records), fewer IOs; 2) Leaf nodes linked for efficient range queries; 3) Non-leaf nodes only store keys, more keys per page. Follow-up: Clustered vs non-clustered index? Clustered index leaves store full row data (primary key index), non-clustered index leaves store primary key values (secondary index), querying non-indexed columns requires a table lookup.

28. Transaction isolation levels?

Read Uncommitted (dirty reads), Read Committed (non-repeatable reads), Repeatable Read (phantom reads, MySQL default), Serializable. InnoDB resolves most phantom reads at RR level through MVCC + gap locks. MVCC: each row has hidden columns trx_id and roll_pointer, read operations determine visibility through ReadView.

29. MySQL lock mechanisms?

Table locks (low overhead, low concurrency), row locks (high overhead, high concurrency), gap locks (lock index gaps to prevent phantom reads), next-key locks (row lock + gap lock). InnoDB row locks are on indexes — without using an index, it degrades to a table lock! Must-know: How to check lock status? show engine innodb status or query information_schema.INNODB_LOCKS.

30. How to optimize slow queries?

1) EXPLAIN for execution plans; 2) Check if indexes are used; 3) Avoid select *; 4) Avoid index invalidation (functions, implicit conversion, LIKE with leading %, OR); 5) Build indexes properly (leftmost prefix for composite indexes); 6) Pagination optimization (deferred join); 7) Consider sharding for large data volumes.

31. Leftmost prefix principle for composite indexes?

Index (a,b,c) can match a, a,b, a,b,c but not b, c, b,c. However, MySQL's optimizer reorders, so WHERE b=1 AND a=2 can still use the index. Columns after range queries don't use the index: WHERE a>1 AND b=2, only a uses the index.

32. MySQL master-slave replication principles?

Master writes binlog → Slave IO thread pulls binlog and writes relay log → Slave SQL thread executes relay log. Async replication may lose data; semi-sync replication requires at least one slave to confirm receiving binlog. Follow-up: How to handle replication lag? Read from your own master, force master reads, check seconds_behind_master.

33. Database sharding strategies?

Vertical split (by business), horizontal split (by rules). Shard key selection: high-frequency query fields. Middleware: ShardingSphere, MyCat. Post-sharding issues: distributed transactions, cross-shard joins, global IDs (snowflake algorithm), data migration.

34. Meaning of EXPLAIN's type field?

From best to worst: system > const > eq_ref > ref > range > index > ALL. Aim for at least range level, avoid ALL (full table scan). Using index in Extra means covering index (good), Using filesort and Using temporary need optimization.

5. Redis (6 Questions)

35. Why is Redis fast?

1) Pure in-memory operations; 2) Single-threaded avoids context switching and lock contention; 3) IO multiplexing (epoll); 4) Efficient data structures. Follow-up: Why did Redis 6.0 introduce multithreading? To improve network IO performance — command execution is still single-threaded.

36. Redis data structures?

5 basic types: String, List, Hash, Set, ZSet. Underlying encodings: String uses SDS, List uses quicklist, Hash uses ziplist/hashtable, Set uses intset/hashtable, ZSet uses ziplist/skiplist+hashtable. Interviewers love asking: Why skiplist instead of red-black tree? Simpler implementation, convenient range queries, insertion only adjusts adjacent nodes.

37. Redis persistence methods?

RDB (snapshot, fast recovery but may lose data) and AOF (append log, data safe but large files). Hybrid persistence: RDB for full + AOF for incremental. Three AOF fsync strategies: always (every command), everysec (every second), no (OS decides). Recommended: everysec.

38. Redis cache penetration, breakdown, and avalanche?

Penetration (querying non-existent data): Bloom filter, cache null values. Breakdown (hot key expires): mutex lock, hot key never expires. Avalanche (mass key expiration): random expiration times, multi-level caching, rate limiting and degradation. These three are almost always tested — you must be able to state complete solutions.

39. Redis cluster solutions?

Master-slave replication (read-write separation), Sentinel (automatic failover), Cluster (sharded storage with 16384 slots). Cluster approach: client calculates slot via CRC16(key) % 16384, each node handles a portion of slots. Follow-up: Can the cluster guarantee strong consistency? No, async replication may lose data.

40. How to implement Redis distributed locks?

SET key value NX EX 30 (atomic operation). Use UUID for value to prevent accidentally deleting someone else's lock. Release lock with Lua script for atomicity: check if value matches then delete. Redisson framework provides watchdog auto-renewal. Follow-up: RedLock algorithm? Multiple Redis instances, lock succeeds only if majority acquired, but it's controversial.

6. Message Queues (5 Questions)

41. Why use message queues?

Decoupling, async processing, peak shaving. Downsides: increased system complexity (duplicate consumption, message loss, ordering issues), reduced availability. Interviewers ask: How to ensure no message loss? Producer confirmation + MQ persistence + consumer manual ACK.

42. Kafka architecture and core concepts?

Producer → Broker (Topic → Partition → Replica) → Consumer Group. Partition is the unit of parallelism; within the same Consumer Group, one Partition can only be consumed by one Consumer. ISR mechanism: Leader maintains a set of in-sync replicas; only ISR replicas can become the new Leader.

43. How does Kafka ensure message ordering?

Messages within the same Partition are ordered. For global ordering, you can only use one Partition (not recommended). Practical approach: send messages with the same business key to the same Partition. Follow-up: What about duplicate consumption from Consumer rebalance? Idempotent processing.

44. Differences between RocketMQ and Kafka?

RocketMQ supports transaction messages, delayed messages, and message backtracking; Kafka has higher throughput and better ecosystem. RocketMQ uses NameServer (stateless), Kafka uses ZooKeeper. Selection: Kafka for log collection, RocketMQ for business messages.

45. How to handle message backlog?

Emergency: increase Consumer count (note: can't exceed Partition count), temporarily scale up Consumers. Long-term: investigate slow consumption causes, optimize consumption logic, increase Partitions. I once encountered 5 million messages backlogged in production — turned out to be slow DB queries on the consumer side.

7. Distributed Systems (5 Questions)

46. CAP theorem and BASE theory?

CAP: Consistency, Availability, Partition tolerance — you can only have two of three. Since network partitions are inevitable, it's CP or AP. BASE: Basically Available, Soft state, Eventually consistent — an extension of AP in CAP. ZooKeeper is CP (unavailable during elections), Eureka is AP (no strong consistency).

47. Distributed lock implementation approaches?

Redis (SET NX EX), ZooKeeper (ephemeral sequential nodes), MySQL (unique index or FOR UPDATE). Comparison: Redis has high performance but average reliability, ZK is reliable but low performance, MySQL is simplest but not for high concurrency. Practical recommendation: Redis + Redisson.

48. Distributed transaction solutions?

2PC (strong consistency but blocking), TCC (Try-Confirm-Cancel, high business intrusion), SAGA (long transaction splitting + compensation), Local message table + MQ (eventual consistency), Seata framework. Common question: What solution does your project use? Most internet projects are fine with eventual consistency.

49. Distributed ID generation approaches?

UUID (unordered, too long), Database auto-increment (performance bottleneck), Segment mode (fetch a batch at once), Snowflake algorithm (timestamp + machine ID + sequence, trend-increasing), Redis auto-increment. Snowflake issue: clock drift (reserve a few bits for drift detection).

50. Difference between circuit breaking and degradation?

Circuit breaking is the caller protecting itself (disconnect after consecutive failures, like a fuse), degradation is proactively abandoning non-core functions to preserve core ones (return default or fallback data). Both Sentinel and Hystrix support this. Three circuit breaker states: closed → open → half-open (probe recovery).

Summary of Real Questions

The above 50 questions are high-frequency questions I encountered in real interviews at ByteDance, Alibaba, Meituan, Kuaishou, and other major tech companies. The Top 10 most frequently asked: JVM memory model, GC algorithms, synchronized vs ReentrantLock, thread pool parameters, AQS, Spring circular dependencies, MySQL indexes, transaction isolation levels, Redis cache trilogy, and distributed locks. I recommend preparing from highest to lowest frequency.

Tips and Advice

1. Don't just memorize — understanding principles is the only way to handle follow-up questions. One "why" from the interviewer filters out those who just recite answers.

2. Build a knowledge graph — JVM→GC→Tuning is one chain, synchronized→Lock Upgrading→AQS is another. Connecting them makes memory more solid.

3. Combine with project experience — prepare a real scenario for each knowledge point. For example, "I encountered OOM in my project and found through jmap that it was a memory leak from not calling ThreadLocal.remove()."

4. Read some source code moderately — you don't need to read everything, but AQS's acquire/release, Spring's getBean flow, and HashMap's put flow are worth tracing through.

5. Mock interviews — practice with a partner. Being able to say it and being able to write it are different things, and expressing it fluently is yet another level.

FAQ

Q: How thoroughly should I memorize these?

A: At minimum, you should be able to explain each topic completely in your own words, key terminology must be accurate, and you should handle one level of follow-up. For example, after explaining the JVM memory model, if the interviewer asks "what's the difference between the method area and metaspace," you need to answer.

Q: Is preparing just these enough?

A: No. These are the foundation — you also need project experience, algorithms, and system design. But if you can't pass the fundamentals, nothing else matters.

Q: Do experienced and new grad hires focus on the same things?

A: New grads focus more on fundamental principles (JVM, concurrency, collections), experienced hires focus more on practical experience (tuning, troubleshooting, architecture selection). Experienced hires must tie answers to real projects, not just recite.

Q: How long to prepare all 50 questions?

A: With Java basics, 2-3 weeks of focused preparation. I recommend 5-8 questions per day — understand each, write notes, and be able to explain verbally. Don't rush — depth beats quantity.