Why Using synchronized on a Local Variable Fails to Lock in Java Multithreading

During a code review the author discovered a Java senior engineer mistakenly used synchronized on a locally created object, believing it would protect shared data across threads.

The original program creates two threads that both execute MyThread.run() , where a new Object is instantiated inside the method and used as the monitor:

package com.sample.interview.multithread;

public class SynchronizedTest {
    public static void main(String[] args) {
        MyThread myThread = new MyThread();
        Thread t1 = new Thread(myThread, "线程1");
        Thread t2 = new Thread(myThread, "线程2");
        t1.start();
        t2.start();
    }
}

class MyThread implements Runnable {
    private static int count = 0;

    @Override
    public void run() {
        Object obj = new Object();
        synchronized (obj) {
            for (int i = 0; i < 3; i++) {
                System.out.println("当前线程：" + Thread.currentThread().getName() + ",数值为：" + (count++));
            }
        }
    }
}

Because each thread creates its own obj , the two monitors are different, so the synchronized block does not serialize the execution. The sample output shows interleaved prints from both threads, e.g.:

当前线程：线程2,数值为：1
当前线程：线程1,数值为：0
当前线程：线程2,数值为：2
当前线程：线程1,数值为：3
当前线程：线程2,数值为：4
当前线程：线程1,数值为：5

The article then modifies the code by making the lock object a class‑level static field (instead of a local variable). After this change the output becomes ordered, confirming that the threads now contend for the same monitor:

当前线程：线程1,数值为：0
当前线程：线程1,数值为：1
当前线程：线程1,数值为：2
当前线程：线程2,数值为：3
当前线程：线程2,数值为：4
当前线程：线程2,数值为：5

Debugging screenshots illustrate the thread states: one thread is RUNNING while the other is in the MONITOR (blocked) state, waiting for the lock to be released. The conclusion is that synchronizing on a local variable does not provide mutual exclusion; the lock must be a shared object, typically a field, to be effective.