http://dikar.iteye.com/blog/1.

the article points out that read-write locks are used to solve the problem of thread block: I tend to use IO bottleneck as the most important factor; in addition, the practice of static one Logger per call place provided by him at the end of the article does not solve the problem of lock competition.
the content of the blog post is as follows:
often encounters thread block residence problems caused by log4j errors under high concurrency. The code snippets that often encounter problems are as follows:

Java Code

public void callAppenders(LoggingEvent event) {  
 int writes = 0;  

 for(Category c = this; c != null; c=c.parent) {  
 // Protected against simultaneous call to addAppender, removeAppender,... 
 synchronized(c) {  
 if(c.aai != null) {  
      writes += c.aai.appendLoopOnAppenders(event);  
    }  
 if(!c.additive) {  
 break;  
    }  
      }  
    }  

 if(writes == 0) {  
      repository.emitNoAppenderWarning(this);  
    }  
  }  

there will be a sync block inside, and along with this Synchronize block may cause a lock competition that makes cpu feel like a hang resident.
there is already a bug, for this problem. See https://issues.apache.org/bug.
also proposes a new solution for this bug, using rw lock.
however, this problem can still occur if you do not upgrade log4j, in the case of misuse. In view of this, colleagues put forward the best use method to avoid this problem. It is very simple that the log object needs to be static every time it is used. The white point is
Java code

private static final Log log = LogFactory.getLog ("xxx");
incidentally, there happens to be an article related to log4J deadlock
Log4j Thread Deadlock-A Case Study
http://java.dzone.com/article.