Just as an academic question, what do you think of an architecture where the various debug/info/error etc. calls on Logger all put something like a LoggingEvent (though probably an immutable equivalent) on a blocking queue, and a single thread takes events off the top of the queue and calls the appenders with it? Then appender calls would be done in a single threaded way, and so an appender implementation would not need to worry about thread safety. My take on the pros and cons of such an architecture: Pros: Using the proven j.u.concurrent queues for thread safety is simpler and safer than rolling your own No need for individual appender implementations to worry about thread safety An application thread isn't slowed down by the I/O involved in appending Cons: Makes your app multi-threaded even in a single threaded environment (mind you, using just about any JVM does this anyway...) The single consumer thread may be flooded by multiple producer application threads, particularly in a web app where you may have a large number of threads logging - that's a memory leak unless you use a bounded buffer, and if you use a bounded buffer then you may suddenly find yourself with random delays as the application threads block waiting for the logging consumer thread to take events off the queue. However, you could mitigate this by deliberately making particular appenders hand off their work asynchronous so that you had more threads doing the actual logging work. Not seriously suggesting that Logback makes such a radical change in architecture, just wondering what people thought of the concept - is there something I'm missing? Would the problem Joern is experiencing with multiple threads competing for a lock and only one of them getting the lock still occur?