Backend Development 18 min read

Master TP-Link Backend Interview: JVM, GC, Synchronization, and Redis Cache Strategies

The article shares a personal experience of TP-Link's early campus recruitment and salary expectations, then provides a comprehensive Java backend interview guide covering class‑loader delegation, JVM memory layout, garbage‑collector types, synchronized lock mechanics, and common Redis cache pitfalls with practical solutions.

IT Services Circle
IT Services Circle
IT Services Circle
Master TP-Link Backend Interview: JVM, GC, Synchronization, and Redis Cache Strategies

Author Xiao Lin discusses TP-Link's early campus recruitment batch, noting that some students received offers a year before graduation and that salaries for the 25th batch often exceed 300k RMB annually.

TP-Link Early Batch Interview

What is the parent‑delegation model and why is it needed?

The parent‑delegation model is a class‑loader mechanism where a class‑loader forwards loading requests to its parent until the bootstrap loader; only if the parent cannot load the class does the child attempt it. This prevents duplicate class loading, protects core Java classes from being overridden, and maintains a clear class‑loader hierarchy.

Avoid duplicate loading : ensures a class like java.lang.Object is loaded only once.

Protect core classes : prevents user‑defined classes from replacing core classes such as java.lang.String .

Maintain hierarchy : guarantees loading order follows the loader hierarchy.

JVM Memory Model Overview

The JVM runtime memory consists of the program counter, Java virtual machine stack, native method stack, heap (young and old generations), method area (metaspace), runtime constant pool, and direct memory.

Program Counter : points to the current bytecode instruction for each thread.

Java Stack : stores frames with local variables, operand stack, etc.

Native Method Stack : similar to Java stack but for native methods.

Heap : shared memory for object instances, divided into Eden, Survivor, and old generations.

Metaspace : stores class metadata, constant pool, and static variables.

Runtime Constant Pool : part of metaspace holding literals and symbolic references.

Direct Memory : off‑heap memory accessed via NIO, improving I/O performance.

Java Garbage Collectors

Serial (copying) – single‑threaded, simple and efficient for young generation.

ParNew – multithreaded version of Serial.

Parallel Scavenge – high‑throughput young‑gen collector.

Serial Old – single‑threaded old‑gen collector.

Parallel Old – parallel old‑gen collector.

CMS – concurrent mark‑sweep, low pause time.

G1 – region‑based collector that reduces fragmentation.

Synchronized Underlying Principle

Synchronized uses a monitor lock implemented by the OS. Bytecode inserts monitorenter and monitorexit instructions. When a thread acquires the lock, the lock count increments; other threads wait. Releasing the lock decrements the count, and when it reaches zero the lock is freed.

Threads enter the entry list when reaching a synchronized block.

One thread obtains the monitor lock, increasing the count.

If a thread calls wait , it releases the lock and moves to the wait set.

Upon method exit or notify , the lock is released and the count decremented.

Redis Cache Issues and Solutions

Cache Avalanche : massive simultaneous expiration or Redis outage causes a flood of DB requests, potentially crashing the database.

Cache Breakdown : a hot key expires, leading many requests to hit the DB and overwhelm it.

Cache Penetration : requests for non‑existent data miss both cache and DB, causing repeated DB load.

Solutions:

Stagger expiration times with random offsets.

Use a mutex lock to ensure only one request rebuilds a missing cache entry.

Make hot data “permanent” in cache and refresh it asynchronously.

Reject illegal requests early, cache empty values, or employ Bloom filters to filter non‑existent keys.

Redis and MySQL Data Synchronization

Read‑through cache strategy: on cache miss, load from DB and populate cache. Write strategy: update DB first, then delete the cache entry.

Cache introduces eventual consistency (CAP’s AP). To achieve final consistency, use retry mechanisms or subscribe to MySQL binlog (e.g., via Canal) and delete cache via a message queue.

Retry deletion via MQ if the first attempt fails.

Subscribe to binlog, parse changes, and delete corresponding cache entries.

Canal simulates a MySQL slave, receives binlog streams, converts them to structured data, and allows downstream services to react, ensuring cache consistency.

JavaJVMRedisGarbage CollectionCache ConsistencySynchronizationBackend Interview
IT Services Circle
Written by

IT Services Circle

Delivering cutting-edge internet insights and practical learning resources. We're a passionate and principled IT media platform.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.