OPPO 2026 Campus Hiring: Salary Insights and In‑Depth Java Exception & Concurrency Guide

OPPO’s 2026 campus recruitment has started to announce offers. The disclosed salaries for backend positions are 20‑22k × 15, 23‑24k × 15, and 25‑26k × 15 (all in Shenzhen), while algorithm (large‑model) roles range from 25.5k × 15 to 29.5k × 15, with additional 1.2k monthly living/house subsidies and a 5% housing fund contribution. Annual packages exceed 300k.

The first interview for backend roles is generally straightforward, focusing on common questions. The second round asks candidates to present their projects and probes deeper into their implementations.

Exception vs. Error

All exceptions inherit from java.lang.Throwable. Exception represents conditions that a program can catch and handle, and it is divided into Checked Exception (must be handled) and Unchecked Exception (may be ignored). Error denotes serious problems that the JVM cannot recover from, such as VirtualMachineError, OutOfMemoryError, or NoClassDefFoundError, which are not meant to be caught.

Checked vs. Unchecked Exceptions

Checked Exception must be either caught with catch or declared with throws during compilation; otherwise the code will not compile. Typical checked exceptions include ClassNotFoundException and SQLException. Unchecked Exception (subclass of RuntimeException) does not require explicit handling; examples are NullPointerException, IllegalArgumentException, NumberFormatException, ArrayIndexOutOfBoundsException, ClassCastException, ArithmeticException, and SecurityException.

The author prefers using unchecked exceptions by default, treating them as bugs that should be exposed and fixed rather than wrapped in try‑catch. Checked exceptions are used only when an exception is part of business logic that callers must handle, such as a “balance insufficient” scenario.

ClassNotFoundException vs. NoClassDefFoundError

ClassNotFoundException

is an Exception that occurs during dynamic class loading (e.g., reflection) and can be caught. NoClassDefFoundError is an Error that happens when a class present at compile time cannot be linked at runtime (e.g., missing JAR), indicating an environment problem.

Java Reference Types

Java defines four reference strengths: strong, soft, weak, and phantom. Strong references are ordinary object references that prevent garbage collection. Soft references ( SoftReference) are cleared only when memory is low and are useful for caches. Weak references ( WeakReference) are cleared eagerly and are often used with ReferenceQueue. Phantom references ( PhantomReference) do not prevent collection and are used to track object finalization.

String strongReference = new String("abc");
SoftReference<String> softReference = new SoftReference<String>(strongReference);
WeakReference<String> weakReference = new WeakReference<>(strongReference);
ReferenceQueue queue = new ReferenceQueue();
PhantomReference<String> phantom = new PhantomReference<String>(strongReference, queue);

StringBuffer Thread Safety

StringBuffer

achieves thread safety by declaring most public methods (e.g., length, append, insert) as synchronized. This ensures that only one thread can execute these methods on a given instance at a time, unlike StringBuilder, which has no such locking and is therefore faster but not thread‑safe.

Why HashMap Is Not Thread‑Safe

Concurrent writes to a HashMap can cause data loss (one thread’s put overwriting another) and, in JDK 7 and earlier, may lead to infinite loops during rehashing when a linked‑list bucket forms a cycle. Example with two threads colliding on the same bucket demonstrates how interleaved execution can result in only one entry being stored.

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
    // ... hash collision handling ...
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
        // ...
    }
}

When two threads simultaneously execute if (++size > threshold) during resizing, the size may be incremented only once, causing an incorrect map size and potential data loss.

ConcurrentHashMap Implementation

In JDK 7, ConcurrentHashMap uses segment locks: the map is divided into Segment objects, each extending ReentrantLock. Each segment protects its own bucket array ( HashEntry) allowing up to 16 concurrent writes (default segment count).

static class Segment<K,V> extends ReentrantLock implements Serializable { }

Since JDK 8, the segment lock has been removed. The map now relies on Node + CAS + synchronized for concurrency, with a structure similar to HashMap (array of bins that become linked lists or red‑black trees). Synchronization is applied only to the head node of a bin, reducing contention.

synchronized vs. volatile

volatile

provides lightweight visibility guarantees for variables and is faster than synchronized, but cannot be used on methods or blocks. synchronized ensures both visibility and atomicity, can protect critical sections, and can be applied to methods or code blocks. volatile guarantees visibility but not atomicity; synchronized guarantees both. volatile solves variable visibility across threads, whereas synchronized coordinates access to shared resources.

Modern JVMs have optimized synchronized with techniques such as biased locking, lightweight locking, and lock elision, making it practical for many production scenarios.