I have my own logging engine which writes the logs on a separate thread with a blocking queue. For the sake of using "standard software" I am thinking about switching to log4j.
I don't want my highly concurrent software to be slowed down by log commands that write everything to disk as some as the command is called. Can log4j be used as a dumpster instead?
Log4j is the logging implementation on most JavaEE app-servers out there, so that's a good advert for its concurrency abilities.
Having said that, I have seen Log4j 1.2 deadlock under high load conditions. A bit of investigation highlighted some scarily bad synchronization in the source code. Apparently, this was fixed in Log4j 1.3, although development on this has slowed or stopped altogether - I get the feeling much of the source was unsalvageable.
However, if you're free to choose, then you should consider Logback instead, the spiritual successor to Log4j. It's a ground-up redesign, and is probably a better option for you.
Check out log4j's asynchronous appender, it buffers log messages ad passes them on to appenders using a separate thread. It might be that you decide the log4j async appender is not appropriate (here are some complaints about it), you could always make your own appender.
来源：https://stackoverflow.com/questions/6089399/concurrent-log4j