synchronized Keyword in Java: Intrinsic Locks and Thread Safety

package io.thecodeforge.concurrency;

import java.util.concurrent.atomic.AtomicInteger;

/**
 * Thread-safe counter implementation demonstrating three approaches:
 * synchronized method, synchronized block, and lock-free AtomicInteger.
 *
 * io.thecodeforge: Production counters should use AtomicInteger for
 * single-variable operations. synchronized is shown here for educational
 * contrast — use it when protecting multi-step compound operations.
 */
public class ForgeCounter {

    // ---- Approach 1: plain int — NOT thread-safe ----
    // count++ compiles to three bytecode instructions: load, add, store.
    // Two threads can interleave between any two of them and lose an update.
    private int unsafeCount = 0;

    // ---- Approach 2: synchronized method — thread-safe, coarser granularity ----
    private int syncCount = 0;

    // ---- Approach 3: AtomicInteger — thread-safe, no lock overhead ----
    // Preferred for single-variable counters in production.
    private final AtomicInteger atomicCount = new AtomicInteger(0);

    // ---- Private final lock object — never synchronize on 'this' in production ----
    // Using 'this' exposes your lock to external code. A private final Object
    // is invisible outside this class and its reference never changes.
    private final Object lock = new Object();

    /**
     * Synchronized method — uses the 'this' instance monitor.
     * All synchronized methods on this instance share the same lock.
     * Only one can execute at a time across all threads.
     */
    public synchronized void incrementSync() {
        syncCount++; // now atomic: only one thread enters at a time
    }

    /**
     * Synchronized block on a private lock — preferred over synchronized method.
     * Minimises the locked region: only the write to syncCount is protected.
     * Any non-shared computation happens outside the lock.
     */
    public void incrementWithBlock(String callerInfo) {
        // Non-shared computation outside the lock — no need to hold it here
        String logLine = "Increment requested by: " + callerInfo;

        synchronized (lock) {
            // Only the critical section is locked
            syncCount++;
        }

        // Logging outside the lock — no need to hold the monitor for this
        System.out.println(logLine + " completed.");
    }

    /**
     * Lock-free increment using AtomicInteger.
     * Uses a hardware CAS instruction — no lock, no blocking, scales better.
     * Preferred for simple counter increments in production.
     */
    public int incrementAtomic() {
        return atomicCount.incrementAndGet();
    }

    /**
     * Synchronized read — required if writes are synchronized.
     * Without synchronizing the read, the happens-before guarantee does not apply
     * and the reader may see a stale cached value from its CPU core.
     */
    public synchronized int getSyncCount() {
        return syncCount;
    }

    public int getAtomicCount() {
        return atomicCount.get(); // volatile read — always sees the latest value
    }

    /**
     * Demonstrates reentrancy: a thread holding the monitor can re-acquire it.
     * Without reentrancy, this call chain would deadlock.
     */
    public synchronized void reentrantOuter() {
        System.out.println("Outer: hold count is now 1");
        reentrantInner(); // re-acquires the same monitor — hold count becomes 2
        System.out.println("Outer: hold count is back to 1 after inner returns");
    }

    public synchronized void reentrantInner() {
        System.out.println("Inner: same thread re-acquired the lock without deadlock");
        // hold count returns to 1 when this method exits
    }
}

package io.thecodeforge.concurrency;

import java.util.ArrayList;
import java.util.List;

/**
 * Demonstrates correct and incorrect lock objects.
 * io.thecodeforge: The lock object identity is the entire mechanism.
 * If threads lock on different objects, synchronization is silently bypassed.
 */
public class LockingPitfall {

    // ---- CORRECT: private final Object as the lock ----
    // Private: external code cannot synchronize on it.
    // Final: the reference never changes — threads always lock on the same object.
    private final Object forgeLock = new Object();
    private final List<String> sharedList = new ArrayList<>();

    /**
     * CORRECT: both methods use forgeLock — mutual exclusion is guaranteed.
     */
    public void addDataCorrect(String data) {
        synchronized (forgeLock) {
            sharedList.add(data);
        }
    }

    public int getSizeCorrect() {
        synchronized (forgeLock) {
            return sharedList.size(); // must synchronize reads too
        }
    }

    /**
     * WRONG #1: mixing 'this' and forgeLock for the same shared data.
     * addDataCorrect() and this method do NOT block each other.
     * Both can run concurrently, corrupting sharedList.
     */
    public void addDataWrongLock(String data) {
        synchronized (this) {         // different monitor from forgeLock
            sharedList.add(data);     // no mutual exclusion with addDataCorrect
        }
    }

    /**
     * WRONG #2: synchronizing on a mutable field.
     * If this.listLock is reassigned between method calls, threads lock
     * on different objects. The reassignment can happen at any time.
     */
    private Object mutableLock = new Object(); // NOT final — dangerous

    public void addDataMutableLock(String data) {
        synchronized (mutableLock) {   // mutableLock may have been reassigned
            sharedList.add(data);      // no longer safe
        }
    }

    public void reassignLock() {
        mutableLock = new Object();    // now threads will lock on different objects
    }

    /**
     * WRONG #3: synchronizing on a String literal.
     * Java interns String literals — "forge-lock" is the same object everywhere
     * in the JVM. Any other class using synchronized("forge-lock") contends
     * with this method, even if it has nothing to do with this class.
     */
    public void addDataStringLock(String data) {
        synchronized ("forge-lock") { // NEVER do this
            sharedList.add(data);
        }
    }

    /**
     * Demonstrates the lock identity diagnostic.
     * Use System.identityHashCode to verify all synchronized blocks
     * reference the same object instance.
     */
    public void diagnoseLockIdentity() {
        System.out.println("forgeLock identity: " + System.identityHashCode(forgeLock));
        System.out.println("this identity:      " + System.identityHashCode(this));
        // If these are different, mixed use of forgeLock and 'this' is a bug.
    }
}

package io.thecodeforge.concurrency;

import java.util.concurrent.locks.ReentrantLock;

/**
 * Demonstrates JVM lock escalation and the practical performance difference
 * between synchronized (blocking) and ReentrantLock (interruptible, timeout).
 *
 * io.thecodeforge: Use JFR to observe lock contention in production.
 * Command: jcmd <pid> JFR.start duration=60s filename=locks.jfr settings=profile
 */
public class LockEscalationDemo {

    private final Object monitor = new Object();
    private final ReentrantLock reentrantLock = new ReentrantLock();
    private int sharedCounter = 0;

    /**
     * Uncontended access: lightweight locking (CAS) — fast.
     * A single thread repeatedly acquiring and releasing the same lock
     * will use only CAS operations — no OS involvement.
     */
    public void singleThreadAccess() {
        for (int i = 0; i < 1_000_000; i++) {
            synchronized (monitor) {
                sharedCounter++;
            }
        }
        System.out.println("Single-thread result: " + sharedCounter);
    }

    /**
     * Contended access: JVM escalates to heavyweight locking under pressure.
     * 16 threads competing for the same monitor — context switches dominate.
     * Compare throughput to the lock-free version below.
     */
    public void heavilyContendedSync() throws InterruptedException {
        sharedCounter = 0;
        Thread[] threads = new Thread[16];
        for (int t = 0; t < threads.length; t++) {
            threads[t] = new Thread(() -> {
                for (int i = 0; i < 100_000; i++) {
                    synchronized (monitor) {
                        sharedCounter++;
                    }
                }
            }, "ForgeWorker-" + t);
        }
        long start = System.nanoTime();
        for (Thread thread : threads) thread.start();
        for (Thread thread : threads) thread.join();
        long elapsed = System.nanoTime() - start;
        System.out.printf("synchronized (16 threads): result=%d, elapsed=%dms%n",
                sharedCounter, elapsed / 1_000_000);
    }

    /**
     * ReentrantLock with tryLock — avoids blocking indefinitely.
     * If the lock is unavailable after 100ms, the thread records a miss
     * and moves on rather than blocking the caller thread.
     *
     * This is the pattern to use when synchronized's lack of timeout support
     * would cause unacceptable latency spikes under contention.
     */
    public void tryLockExample() throws InterruptedException {
        Thread[] threads = new Thread[4];
        for (int t = 0; t < threads.length; t++) {
            final int id = t;
            threads[t] = new Thread(() -> {
                try {
                    if (reentrantLock.tryLock(100, java.util.concurrent.TimeUnit.MILLISECONDS)) {
                        try {
                            sharedCounter++;
                            System.out.println("Thread-" + id + " acquired lock and incremented");
                        } finally {
                            reentrantLock.unlock(); // always unlock in finally
                        }
                    } else {
                        System.out.println("Thread-" + id + " could not acquire lock in 100ms — skipping");
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }, "ForgeTryLock-" + id);
        }
        for (Thread thread : threads) thread.start();
        for (Thread thread : threads) thread.join();
    }

    /**
     * Diagnosing lock contention at runtime.
     * Use this pattern in a health-check or metrics endpoint.
     */
    public void reportLockContention() {
        System.out.println("ReentrantLock queue length: " + reentrantLock.getQueueLength());
        System.out.println("ReentrantLock hold count:   " + reentrantLock.getHoldCount());
        System.out.println("Is lock held by any thread: " + reentrantLock.isLocked());
        // synchronized monitors cannot be inspected this way — another advantage of ReentrantLock
    }
}