Crack OPPO Backend Interview: Java Multithreading, Redis Locks, MySQL Indexes & More

Hello, I’m Xiao Lin. Recently OPPO released its 2023 campus recruitment salaries, and here are the known figures:

Application Development: 22k × 15, Nanjing, Master

Backend Development: 24k × 15 + 1.2k × 12 (housing subsidy), Master, Shenzhen

Backend Development: 20k × 15 + 1.2k × 12 (housing subsidy), Bachelor, Shenzhen

C++ Development: 22k × 15, Chengdu, Master

The 1,200 CNY monthly housing subsidy is only for base salaries in Shenzhen; second‑tier cities do not receive it. Compensation is base salary plus a three‑month year‑end bonus, with no signing fee or equity at present.

In my view, 20–22k is a “basic” offer, while 24k is a strong (SP) offer. The market hasn’t changed much compared to last year; a top‑tier (SSP) offer could reach around 26k.

Below is the OPPO autumn‑recruitment interview I experienced for a backend position.

OPPO (Backend Development – First Round)

1. What is Java multithreading and what should be considered?

Java multithreading allows multiple threads to run concurrently within a single JVM, sharing the same memory space while each thread has its own stack and program counter.

Key considerations:

Thread safety – use synchronized or Lock to protect shared data.

Thread communication – coordinate producer/consumer threads with wait() and notify().

Thread creation cost – employ a thread pool to reuse threads and reduce overhead.

2. What are the differences between HashMap and ConcurrentHashMap?

JDK 1.7 version:

Memory structure : HashMap uses an array + linked list; ConcurrentHashMap uses an array of Segment objects, each acting like a small HashMap with its own lock.

Thread safety : HashMap is not thread‑safe; ConcurrentHashMap provides thread safety via segment locks, allowing concurrent access to different segments.

Performance : In single‑threaded scenarios HashMap is faster; under concurrency ConcurrentHashMap achieves higher throughput due to reduced lock contention.

JDK 1.8 version:

Memory structure : HashMap adds a red‑black tree when a bucket’s linked list exceeds a threshold; ConcurrentHashMap drops segment locks and uses CAS plus synchronized, retaining the same array + list/tree structure.

Thread safety : HashMap remains non‑thread‑safe; ConcurrentHashMap ensures safety with CAS and synchronized blocks.

Performance : Both benefit from the red‑black tree for long chains, but ConcurrentHashMap’s lock‑free design further improves concurrency.

3. What locking mechanisms does Redis provide?

1) SETNX lock (basic lock)

SETNX sets a key only if it does not exist, acting as a lock. To avoid dead locks when a process crashes, add an expiration: SET order_lock 1 NX EX 10.

2) Redisson distributed lock (common in distributed scenarios)

Redisson stores lock information in a Redis hash and runs a watchdog thread that periodically extends the lock’s TTL, preventing premature expiration and supporting re‑entrancy.

3) Redlock (high‑availability distributed lock)

Redlock requires a majority of Redis nodes (e.g., 3 of 5) to acquire the lock, ensuring safety even if some nodes fail.

4. What is MySQL’s underlying data structure?

InnoDB uses a B+Tree for its indexes. A B+Tree stores data only in leaf nodes, while internal nodes contain only index keys. Searching a primary‑key B+Tree typically touches 3–4 nodes, resulting in 3–4 disk I/Os even for millions of rows. SELECT * FROM product WHERE id = 5; The query traverses the root, intermediate, and leaf nodes to locate the row.

5. How do B‑Tree and B+Tree differ?

Data storage: B+Tree stores all data in leaf nodes; B‑Tree stores data in both leaf and internal nodes.

Leaf linkage: B+Tree leaf nodes are linked via a doubly‑linked list, facilitating range queries; B‑Tree leaves are not linked.

Search stability: B+Tree always reaches a leaf node, giving consistent performance; B‑Tree may find data in internal nodes, leading to variable performance.

6. How to diagnose a long‑running process?

1) Identify the PID with ps -ef | grep <process_name> and monitor with top -p PID or htop -p PID to see CPU, memory, and I/O usage.

2) Check the process state (e.g., “D” for uninterruptible I/O wait, “R” for running) using ps -aux | grep PID. Use iostat for disk I/O, pstack PID or gdb attach PID followed by bt to view the call stack.

3) Review logs with tail -f <log_path> and inspect file descriptors via ls -l /proc/PID/fd.

4) Examine external dependencies (databases, network services) using netstat -anp | grep PID or ss -tulnp | grep PID.

5) If needed, generate a core dump with gcore PID and analyze with gdb, jstack, or jmap -histo depending on the language.

7. Common Linux commands

ls

, cd, pwd – file navigation. mkdir, touch, rm, rm -r – create/delete files and directories. cat, more, less, head, tail, tail -f – view file contents. cp, mv – copy and move files. ps, top, kill – process management. df -h, free -h, uname -a, date – system information. chmod, chown – permission management. tar -zcvf, tar -zxvf, zip, unzip – compression. ping, ifconfig / ip addr, netstat -tuln, curl / wget – networking.

8. Database three normal forms

1NF : Each column holds atomic values.

2NF : All non‑key attributes fully depend on the whole primary key (no partial dependencies).

3NF : No transitive dependencies; non‑key attributes depend only on the primary key.

9. Other typical interview questions

What technology stack did the project use?

What was the biggest difficulty and how was it solved?

Explain any additional topics you prepared.