Is Your Spring MVC Controller Thread‑Safe? Understand and Fix It

Understanding Thread Safety in Spring MVC Controllers

Interviewers often ask whether a Spring MVC Controller is thread‑safe. Before answering, we need to understand what thread safety means.

What is thread safety?

Thread safety means that when multiple threads invoke a method simultaneously, the result is always the expected one, independent of the execution order.

Simple unsafe example

The following Java program simulates 100 concurrent threads incrementing a shared counter without synchronization, leading to duplicate and missing values.

import java.util.Random;

public class ThreadTest {
    private int count;

    @SneakyThrows
    public int incCount() {
        Thread.sleep(new Random().nextInt(500));
        return count++;
    }

    public static void main(String[] args) {
        ThreadTest threadTest = new ThreadTest();
        for (int i = 0; i < 100; i++) {
            new Thread(() -> System.out.println(threadTest.incCount())).start();
        }
    }
}

Typical output shows numbers out of order and repeated values, e.g., 12 appears twice, and the final count may be 90 instead of the expected 99.

0
1
2
3
4
5
6
8
7
9
10
11
13
12
12
14
15
…
90

Fixing the problem with synchronization

Adding the synchronized keyword forces each thread to acquire a lock before executing the method, guaranteeing correct results but reducing throughput.

@SneakyThrows
public synchronized int incCount() {
    Thread.sleep(new Random().nextInt(500));
    return count++;
}

Implications for Spring MVC Controllers

Spring MVC Controllers are singletons, and each HTTP request is handled by a separate thread. If a controller holds mutable instance variables, concurrent requests can corrupt the data, making the controller effectively thread‑unsafe.

How to make Controllers thread‑safe

Avoid defining mutable fields in the controller whenever possible.

If shared state is required, protect it with synchronization mechanisms such as synchronized blocks.

For per‑request data, use ThreadLocal or method‑local variables to keep state isolated to each thread.

These practices ensure that the controller remains thread‑safe without sacrificing performance.