Java Backend Interview Core Knowledge: 8 Modules of High-Frequency Topics and Answer Templates

What Do Java Backend Core Knowledge Interviews Really Test?

In technical interviews, Java backend core knowledge questions are mandatory at virtually every major tech company. Whether you're a new grad or experienced hire, interviewers will systematically ask about JVM, concurrency, Spring, databases, and other core modules. They're testing not just "have you memorized it," but "do you understand the principles and can you explain them clearly."

The real evaluation logic of Java interview core knowledge is: using foundational knowledge to assess your technical depth, and using follow-up questions to determine whether you truly understand or just memorized answers. Interviewers are most frustrated by candidates who "memorize answers without understanding" — they fall apart once follow-up questions are asked.

This article systematically covers the 8 most frequent core modules in backend interview questions, listing 3-5 high-frequency topics per module, providing standard answer frameworks, and marking interviewer follow-up directions to help you build a methodology of "understanding principles rather than rote memorization."

Module 1: JVM — Memory Model and Garbage Collection

High-Frequency Topics

• JVM Memory Model: What heap, stack, method area, program counter, and native method stack each store, and whether they're thread-shared
• Garbage Collection Algorithms: Mark-sweep, mark-compact, and copying algorithms — their pros, cons, and applicable scenarios
• Garbage Collectors: Core differences between CMS, G1, and ZGC, and how to choose
• Class Loading Mechanism: What the parental delegation model is, why break it, and how to break it
• JVM Tuning: OOM troubleshooting approach, common JVM parameters, production issue diagnosis

Standard Answer Framework

Using "JVM Memory Model" as an example:

1. Overview: JVM memory is divided into thread-private and thread-shared sections
2. Thread-private: Virtual machine stack (stack frames, local variable table), native method stack, program counter
3. Thread-shared: Heap (object instances, main GC area), method area/metaspace (class info, constant pool)
4. Supplement: After JDK8, permanent generation was replaced by metaspace, which uses native memory

Interviewer Follow-up Directions

"How is heap memory generational? Why does the young generation use the copying algorithm? How to solve CMS's floating garbage problem? How to troubleshoot frequent Full GC in production?" — Follow-ups typically go from concepts to practical scenarios.

Module 2: Concurrent Programming — Thread Safety and Lock Mechanisms

High-Frequency Topics

• Thread States and Lifecycle: Transition relationships between NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED
• synchronized vs ReentrantLock: Implementation principles, functional differences, use cases
• volatile Keyword: Visibility, prevention of instruction reordering, does not guarantee atomicity
• AQS Principles: CLH queue, exclusive/shared modes, Condition queue
• Thread Pools: Core parameters, execution flow, rejection policies, how to configure properly

Standard Answer Framework

Using "Differences between synchronized and ReentrantLock" as an example:

1. Implementation Level: synchronized is a JVM-level keyword, ReentrantLock is an API-level class
2. Functional Differences: ReentrantLock supports fair locks, interruptibility, and multiple condition variables; synchronized does not
3. Release Mechanism: synchronized releases automatically, ReentrantLock requires manual unlock (in finally block)
4. Performance: After JDK6's lock upgrade optimization, the performance difference is negligible
5. Selection Advice: Use synchronized for simple scenarios, ReentrantLock when advanced features are needed

Interviewer Follow-up Directions

"What's the lock upgrade process for synchronized? How is AQS's tryAcquire implemented? How to configure thread pool core thread count? What's the difference between CountDownLatch and CyclicBarrier?"

Module 3: Collections Framework — Underlying Principles and Selection

High-Frequency Topics

• HashMap: Underlying array + linked list + red-black tree, resizing mechanism, reasons for thread unsafety
• ConcurrentHashMap: JDK7 segment locking vs JDK8 CAS + synchronized, why not use HashTable
• ArrayList vs LinkedList: Underlying array vs doubly linked list, performance differences for random access vs insertion/deletion
• Red-Black Tree: Why HashMap converts linked lists to red-black trees when length exceeds 8, why not use red-black trees directly

Standard Answer Framework

Using "HashMap's Underlying Principles" as an example:

1. Data Structure: After JDK8, uses array + linked list + red-black tree, default initial capacity 16, load factor 0.75
2. put Flow: Calculate hash → locate bucket → empty then insert → non-empty then traverse linked list/red-black tree → exists then overwrite → doesn't exist then tail-insert → linked list length ≥8 and array length ≥64 then convert to red-black tree
3. Resizing Mechanism: When element count exceeds capacity × load factor, resize to 2x and redistribute via rehash
4. Thread Unsafety: JDK7 head-insertion caused infinite loops, JDK8 tail-insertion fixed loops but data overwrite issues remain

Interviewer Follow-up Directions

"How is HashMap's hash perturbation function designed? Why must capacity be a power of 2? How is ConcurrentHashMap's size method implemented?"

When preparing for technical interviews, many candidates focus only on studying core knowledge and neglect how they present project experience on their resume. A strong technical resume should highlight your technical depth and engineering practice — use our resume tool to quickly generate a professional resume that showcases your technical strengths, leaving a positive impression before the core knowledge round even begins.

Module 4: Spring Ecosystem — IoC/AOP/Transactions

High-Frequency Topics

• IoC Container: Bean lifecycle, how circular dependencies are resolved (three-level cache), scopes
• AOP Principles: JDK dynamic proxy vs CGLIB, aspect execution order, common application scenarios
• Transaction Management: @Transactional failure scenarios, propagation mechanisms, isolation levels
• SpringBoot Auto-Configuration: @EnableAutoConfiguration principles, starter mechanism

Standard Answer Framework

Using "Spring Bean Lifecycle" as an example:

1. Instantiation: Create Bean instance via constructor
2. Property Assignment: Inject dependent Beans and configuration values
3. Aware Callbacks: BeanNameAware, BeanFactoryAware, ApplicationContextAware
4. Before Initialization: BeanPostProcessor's postProcessBeforeInitialization
5. Initialization: @PostConstruct annotated method, InitializingBean's afterPropertiesSet, custom init-method
6. After Initialization: BeanPostProcessor's postProcessAfterInitialization (AOP proxy generated here)
7. In Use: Bean is available for application use
8. Destruction: @PreDestroy annotated method, DisposableBean's destroy, custom destroy-method

Interviewer Follow-up Directions

"What does each level of the three-level cache store? Can constructor-injected circular dependencies be resolved? What happens when @Transactional is annotated on a private method? Does AOP work for internal calls within the same class?"

Module 5: Databases — Index Optimization and Transaction Isolation

High-Frequency Topics

• Index Principles: B+ tree structure, clustered vs non-clustered indexes, covering indexes, leftmost prefix matching
• Index Invalidation Scenarios: Function operations, implicit type conversion, LIKE left wildcard, OR conditions, not satisfying leftmost prefix
• Transaction Isolation Levels: Read uncommitted, read committed, repeatable read, serializable, and what each solves
• MVCC Principles: Hidden columns, Undo Log, ReadView creation timing
• Lock Mechanisms: Row locks, table locks, gap locks, Next-Key Lock, deadlock troubleshooting

Standard Answer Framework

Using "Why MySQL Uses B+ Trees for Indexes" as an example:

1. vs Hash: Hash doesn't support range queries; B+ tree leaf nodes are linked via linked lists, naturally supporting ranges
2. vs B-Tree: B+ tree non-leaf nodes store only keys without data, allowing more keys per node, making the tree shorter with fewer IOs
3. vs Binary Tree: B+ tree is a multi-way balanced tree with much lower height, reducing disk IO
4. Supplement: Leaf nodes are connected via sorted linked lists, making range queries and sorting efficient

Interviewer Follow-up Directions

"Can a composite index (a,b,c) be used when querying b=1? Can repeatable read solve phantom reads? What's the difference between ReadView in RC and RR under MVCC? How to optimize slow SQL in production?"

Module 6: Caching — Redis Core Scenarios

High-Frequency Topics

• Data Types and Underlying Structures: String(SDS), List(quicklist), Hash(ziplist/hashtable), Set(intset/hashtable), ZSet(ziplist/skiplist+hashtable)
• Three Major Cache Problems: Cache penetration (Bloom filter/null caching), cache breakdown (mutex lock/never expire), cache avalanche (random expiration/multi-level caching)
• Persistence: RDB snapshots vs AOF logs, mixed persistence
• High Availability: Master-slave replication, sentinel mode, Cluster sharding

Standard Answer Framework

Using "Cache Penetration and Solutions" as an example:

1. Definition: Querying data that definitely doesn't exist in the database, with requests passing through the cache directly to the database
2. Impact: Malicious attacks can cause sudden database pressure spikes or even downtime
3. Solution 1: Cache null values — cache null even when not found, with short expiration
4. Solution 2: Bloom filter — add a Bloom filter layer before the cache to intercept non-existent data
5. Solution 3: Rate limiting — restrict frequency of abnormal requests

Interviewer Follow-up Directions

"How to control Bloom filter's false positive rate? How to ensure Redis-database dual-write consistency? How are Redis Cluster hash slots allocated? How to handle big keys?"

Module 7: Message Queues — Decoupling and Peak Shaving

High-Frequency Topics

• Why Use Message Queues: Three core scenarios — decoupling, async processing, peak shaving
• Message Reliability: Producer confirmation mechanism, consumer manual ACK, message persistence
• Message Ordering: How to ensure messages from the same business are consumed in order
• Duplicate Consumption: Idempotent design — unique ID + dedup table, database unique constraint, Redis SETNX

Standard Answer Framework

Using "How to Ensure Messages Are Not Lost" as an example:

1. Producer Side: Use confirm mechanism to verify message arrival at Broker, retry on failure
2. Broker Side: Persist messages to disk, set both queue and message persistence
3. Consumer Side: Manual ACK instead of auto ACK, confirm after processing is complete
4. Compensation Mechanism: Scheduled tasks check for long-unACKed messages, resend or alert

Interviewer Follow-up Directions

"How to choose between Kafka, RabbitMQ, and RocketMQ? How to handle message backlog? How to ensure message ordering? How to implement delayed messages?"

Module 8: Distributed Systems — CAP and Consistency

High-Frequency Topics

• CAP Theorem: Consistency, availability, and partition tolerance cannot all be achieved simultaneously; distributed systems must choose between CP and AP
• BASE Theory: Basically available, soft state, eventually consistent — a practical complement to CAP
• Distributed Locks: Redis implementation (SETNX + expiration + Lua release), ZooKeeper implementation (ephemeral sequential nodes)
• Distributed Transactions: 2PC, TCC, Saga, local message table, best-effort notification
• Consensus Algorithms: Raft election and log replication, basic Paxos principles

Standard Answer Framework

Using "Distributed Lock Implementation Methods" as an example:

1. Redis Implementation: SET key value NX EX seconds, use unique identifier as value to prevent accidental deletion, use Lua script for atomic release
2. ZooKeeper Implementation: Create ephemeral sequential nodes, smallest sequence number acquires the lock, other nodes watch the previous node's deletion event
3. Comparison: Redis has higher performance but slightly weaker reliability (master-slave failover may lose locks), ZooKeeper has higher reliability but lower performance
4. Supplement: Redlock algorithm solves Redis single-point issues but is controversial; in production, choose based on business tolerance

Interviewer Follow-up Directions

"Are there still issues with distributed locks under Redis Cluster? What's the Raft Leader election process? What's the difference between TCC and Saga? Distributed ID generation solutions?"

3 High-Scoring Strategies for Core Knowledge Interviews

Strategy 1: Lead with the Conclusion, Then Expand with Details

When the interviewer asks about "HashMap's underlying principles," don't jump straight into source code. First summarize in one sentence: "HashMap uses an array + linked list + red-black tree structure, locates buckets via hash, resolves collisions with linked lists, and converts to red-black trees beyond a threshold." Then expand layer by layer. This demonstrates structured communication ability, allowing the interviewer to quickly grasp your core point.

Strategy 2: Proactively Connect to Practical Experience

After answering theory, proactively add "I encountered XX issue in a project, which I troubleshot/resolved via XX approach." For example, after explaining JVM garbage collection, add "In production, I dealt with frequent Full GC issues, identified large objects through GC logs, and resolved it after optimization." This proves you're not just theorizing.

Strategy 3: Acknowledge Boundaries, Demonstrate Depth of Thinking

When encountering uncertain questions, don't fabricate answers. You can say "I'm not entirely sure about this detail, but based on my understanding it should be XX because XX." Demonstrating your reasoning process is far better than giving a wrong answer. Interviewers appreciate candidates who understand principles rather than rote memorize.

FAQ

How thoroughly should I memorize core knowledge?

Don't memorize word for word. Understand the principles and explain them in your own words. Interviewers can immediately tell whether you truly understand or just memorized. The key is mastering the answer framework (overview - details - supplement) for each topic and being able to present a coherent explanation.

With so many high-frequency Java interview questions, how can I prepare efficiently?

Tackle each of the 8 modules in this article systematically. Prioritize high-frequency topics (3-5 per module), then expand to medium-frequency ones. Don't try to cover everything — mastering core principles is more effective than casting a wide net. We recommend spending 2-3 days per module, completing one full round in 3-4 weeks.

What if the interviewer's follow-up asks something I don't know?

Be honest and say "I'm not very familiar with this," but try to connect it with knowledge you do have to reason through it. For example, if you don't know ZGC's details, you can say "I know ZGC is a low-latency collector that achieves concurrent compaction through colored pointers and read barriers, but I'd need to study the specific implementation details further." This is much better than silence or making things up.

Which is more important: core knowledge or project experience?

Both are important and complementary. Core knowledge is the threshold, project experience is the differentiator. In technical interviews, core knowledge determines whether you pass the initial round, while project depth determines whether you get a high rating. We recommend splitting preparation time 50/50 between core knowledge and projects.

Do different companies focus on different core knowledge areas?

Yes. ByteDance emphasizes JVM and concurrency, Alibaba emphasizes Spring and distributed systems, Tencent emphasizes networking and databases, Meituan emphasizes Redis and message queues. Adjust your preparation focus based on your target company, but the foundational knowledge across 8 modules is universal — build a solid foundation first, then strengthen targeted areas.

Preparing for technical interviews is a systematic engineering effort, from core knowledge to project experience. A strong technical resume can build the interviewer's confidence before the questioning even begins — use our resume generator to precisely present your technical skills and project achievements, and give your interview an edge.