Log4j 1.2 is vulnerable to deadlocks when toString() produces nested logging.
See old aged still unresolved issues like Log4J can create deadlock conditions (concurrent package donation) and Deadlock with RollingFileAppender.
It also has performance-killing lock synchronization issues under heavy concurrent load.
Like Category callAppenders synchronization causes java.lang.Thread.State: BLOCKED and Move org.apache.log4j.Category to reentrant read/write locks.
Even AsyncAppender is not free of excessive locks:
AsyncAppender.doAppend() does not need to be synchronized and Deadlock in 1.2.15 caused by AsyncAppender and ThrowableInformation classes. Also beware of AsyncAppender overflow.
One caveat is to always constrain root category level to at least INFO or higher. This would prevent logging calls from acquiring unnecessary locks mentioned in the above issues. Just limiting appender threshold is not sufficient as it is taken into account later. See explanation with publish/subscribe analogy:
To answer your question about how threshold interacts with category,
basically think of it is as a publish/subscribe. The category sets
what is published by the logger, the threshold sets the subscription
level of the appender.
Nested categories of interest can be individually given lower priorities if needed.