Diagnosing Intermittent Application Slowdowns Caused by Log4j Logger Lock Contention

During a period of intermittent performance degradation of a SaaS application—both under high and low traffic—the team could only temporarily restore normal operation by restarting the service.

To investigate, they captured a thread dump with the jstack utility while the application was slow and uploaded the dump to the online analysis platform fastthread.io .

The analysis immediately highlighted that the thread http-nio-8080-exec-121 was blocking more than one hundred other threads, as shown in the generated dependency graph.

Further inspection of the blocked threads revealed that they were all waiting to acquire the lock on org.apache.log4j.Logger . The owning thread had obtained the logger lock and was performing other operations without releasing it, causing every subsequent logging attempt to block.

Searching for the symptom led to a known Log4j 1.x bug (see Bug 57714 ) that was first reported in 2015. The bug causes any thread that tries to log to become blocked, effectively freezing the entire application.

The problem disappears once the application migrates from Log4j 1.x to Log4j2, a completely rewritten framework that offers significant performance improvements and is actively maintained.

Conclusion: Log4j 1.x has not been maintained since August 2015; any system still using it should upgrade to Log4j2 to avoid lock‑contention issues and benefit from the newer framework's enhancements.