Java synchronized Keyword: Methods, Blocks and Locks

The synchronized keyword makes a method or a block of code run in only one thread at a time for a given lock object, and it guarantees that the next thread sees all changes made inside it. Every Java object has a built-in lock, called a monitor, and synchronized acquires it on entry and releases it on exit.

We use synchronized to protect shared mutable state, such as a counter, a cache or a bank balance, from race conditions. Without it, two threads can read the same old value and both write back their own update, so one update is lost.

The following example increments a shared counter from two threads. The Counter class is defined in section 1.

Counter counter = new Counter();
Thread t1 = Thread.ofPlatform().start(() -> { for (int i = 0; i < 10_000; i++) counter.increment(); });
Thread t2 = Thread.ofPlatform().start(() -> { for (int i = 0; i < 10_000; i++) counter.increment(); });
t1.join();
t2.join();
int total = counter.get();              // 20000, every time

Without synchronized on increment(), the same code returned values such as 14,544 or 15,173 in some of our runs on Java 25. We look at synchronized methods and blocks, the lock that each form uses, reentrancy and visibility, deadlocks, virtual threads, and when other tools fit better.

1. Synchronized Methods

A synchronized method locks the whole method body. For an instance method, the lock is the object the method is called on, this. Two threads can call the method at the same time only on two different objects.

class Counter {
    private int count;

    synchronized void increment() {
        count++;                         // read, add, write as one step
    }

    synchronized int get() {
        return count;
    }
}

The get() method is synchronized too. Without it, a reader thread is not guaranteed to see the latest value, because the lock also controls memory visibility, as section 4 explains.

A static synchronized method locks the Class object of its class instead of an instance. A static and an instance synchronized method of the same class use different locks, so they can run at the same time and do not protect each other’s data.

2. Synchronized Blocks

A synchronized block locks only the statements inside it, on an object we choose. Keeping the locked part short lets other threads work in parallel during the slow, unshared parts of a method.

class OrderBook {
    private final Object lock = new Object();
    private final List<String> orders = new ArrayList<>();

    void add(String rawOrder) {
        String order = rawOrder.trim().toUpperCase();   // no shared state, no lock
        synchronized (lock) {
            orders.add(order);
        }
    }

    int size() {
        synchronized (lock) {
            return orders.size();
        }
    }
}

OrderBook book = new OrderBook();
book.add("  buy 10 acme ");
int orderCount = book.size();           // 1

A private, final lock object is the safest choice, because no outside code can lock it by accident. Locking on this works too, but any caller that holds a reference to the object can also lock it and block our methods.

3. Which Lock Each Form Uses

Two pieces of code exclude each other only if they lock the same object, so the choice of lock decides what is protected.

Form	Lock object
synchronized void m()	this, the current instance
static synchronized void m()	Counter.class, the Class object
synchronized (lock) { … }	The object that lock refers to
synchronized (Counter.class) { … }	The same lock as static synchronized methods

Some objects make bad locks. A String literal is shared across the whole JVM, and an Integer or other value-based object may be cached and shared. For value-based classes, javac warns when we synchronize on them. A null lock throws NullPointerException when the block starts.

4. Reentrancy and Memory Visibility

Java locks are reentrant. A thread that holds a lock can enter another block or method synchronized on the same lock, and the JVM counts the holds and releases the lock only when the outermost block exits.

class Account {
    private long balance;

    synchronized void deposit(long amount) {
        balance += amount;
    }

    synchronized void depositTwice(long amount) {
        deposit(amount);                 // same thread takes the lock again
        deposit(amount);
    }

    synchronized long balance() {
        return balance;
    }
}

Account account = new Account();
account.depositTwice(50);
long balance = account.balance();       // 100

The second guarantee is happens-before ordering. Everything a thread writes before it releases a lock is visible to the next thread that acquires the same lock. This is why reads need the lock as well as writes, and why synchronized fixes problems that look like stale values.

5. Deadlocks and Waiting

A deadlock happens when two threads each hold one lock and wait for the other’s lock. A classic case is a money transfer that locks the source account first, while another transfer in the opposite direction locks the target first.

The standard fix is a fixed lock order. If every transfer locks the account with the smaller ID first, two threads can never wait for each other in a circle.

record Wallet(int id) {}

static String transfer(Wallet from, Wallet to) {
    Wallet first = from.id() < to.id() ? from : to;
    Wallet second = first == from ? to : from;
    synchronized (first) {
        synchronized (second) {
            return "moved from " + from.id() + " to " + to.id();
        }
    }
}

String move = transfer(new Wallet(2), new Wallet(1));   // "moved from 2 to 1"

Inside a synchronized block, wait() releases the lock and suspends the thread until another thread calls notify() or notifyAll() on the same object. A pause with Thread.sleep keeps the lock, so a thread that pauses inside a synchronized block blocks every other thread that needs it.

6. synchronized and Virtual Threads

In Java 21, a virtual thread that blocked inside a synchronized block stayed pinned to its carrier platform thread, which could exhaust the small carrier pool. Many libraries replaced synchronized with ReentrantLock for that reason.

Java 24 removed that limit with JEP 491. On Java 24 and later, a virtual thread that blocks in a synchronized block or in wait() releases its carrier, so synchronized is again a good default for code that runs on virtual threads.

Counter shared = new Counter();
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1_000; i++) {
        executor.submit(shared::increment);
    }
}
int virtualTotal = shared.get();        // 1000

7. synchronized vs ReentrantLock vs Atomic Classes

The synchronized keyword is the simplest lock, and the JVM releases it even when an exception leaves the block. The java.util.concurrent package offers more specialized tools, and the ReentrantLock guide shows the explicit lock in action.

Tool	Best for
synchronized	Most shared state, short critical sections
ReentrantLock	Timeouts with tryLock(), interruptible waiting, fair ordering, several conditions
AtomicInteger, LongAdder	A single counter or value, without any lock
volatile	A flag that one thread writes and others read, with no compound updates
ConcurrentHashMap	Shared maps with high read and write traffic

AtomicInteger hits = new AtomicInteger();
hits.incrementAndGet();
hits.incrementAndGet();
int hitCount = hits.get();              // 2

8. synchronized Keyword FAQs

Developers who write their first multithreaded code ask these questions.

8.1. Can a constructor be synchronized?

No, the compiler rejects it. Normally only the thread that runs the constructor can see the new object until the constructor returns, so there is nothing to protect yet, unless the constructor lets this escape to other code.

8.2. Is the synchronized modifier inherited?

No. An overriding method in a subclass is not synchronized unless it is declared so, even when the parent method is.

8.3. Does synchronized make code slow?

An uncontended lock costs very little on modern JVMs. The cost comes from contention, when many threads wait for the same lock, so we keep synchronized sections short.

8.4. Do we need synchronized for local variables?

No. Local variables live on the stack of one thread, so other threads cannot see them. Only fields and objects shared between threads need protection.

9. Conclusion

The synchronized keyword gives one thread at a time access to code guarded by the same lock, and it makes changes visible to the next thread that takes that lock. Instance methods lock this, static methods lock the Class object, and blocks lock the object we choose.

We keep critical sections short, use private lock objects, lock in a fixed order to avoid deadlocks, and switch to atomic classes or ReentrantLock when they fit better. Since Java 24, synchronized also works well with virtual threads.

10. References

• JLS 25, The synchronized Statement
• JLS 25, Happens-before Order
• JEP 491, Synchronize Virtual Threads without Pinning
• ReentrantLock (Java SE 25 API)

Happy Learning !!

Source Code on Github