If your Java app feels like it is wading through molasses under load, synchronized methods are a usual suspect. The JVM makes single threaded life cheap, but when threads start arguing over the same monitor, Java will escalate that tiny polite lock into something heavier and slower. That escalated lock means more CPU, more thread stalls, and a bigger headache for your SLA.

What actually happens when a synchronized method gets hot

At low contention the JVM uses thin locks which are fast and stingy with CPU. With contention the runtime inflates the monitor, which brings in operating system assistance and context switches. The visible signs are higher CPU time, frequent thread parking, and long wait durations rather than mysterious memory leaks or random crashes.

Quick checklist for symptoms

• High rate of monitor enter and monitor exit events in traces
• Many threads in blocked or parked state
• Throughput drops as concurrency increases

Measure first, guess later

Do not remove synchronized declarations like you are pruning a bonsai without a plan. Record a production like workload with JFR, then open that recording in JDK Mission Control. Flight Recorder captures monitor events and thread state transitions so you can see how often a monitor is contended and how long threads wait. That is the data driven part you are allowed to enjoy.

Simple measurement workflow

1. Record while exercising the application with a realistic load
2. Open the recording in JDK Mission Control and inspect monitor events and thread states
3. Find hotspots where synchronized methods or blocks dominate wait time
4. Iterate on changes and remeasure until performance targets are met

Practical fixes that actually help

If the hotspot is just a tiny counter update, swapping a synchronized method for an AtomicInteger or a LongAdder often fixes things with little drama. For more complex shared state consider finer grained locks or a StampedLock with optimistic reads. Partitioning state so threads work on different buckets is also a low cost win.

public synchronized void increment() { count++; }

That one line can be fine for single threaded usage or low traffic, but it becomes a bottleneck under high concurrency. Try this instead when appropriate

private final AtomicInteger count = new AtomicInteger();
public void increment() { count.incrementAndGet(); }

Final note from the profiler with a smirk

Profiling with JFR and JDK Mission Control gives you the facts. Optimize where the data points, not your intuition, recommend changes. If synchronized is localized, replace the hotspot with an atomic or a finer grained design and measure again. If you skip measurement you are gambling with production and nobody likes losing to blind confidence.