Minimal (aka fine grained) locking

Details

Description

Most components of log4j 1.2 are not inherently thread-safe but depend on locks that are acquired after the threshold check and are not released until processing is completed. Unless the AsyncAppender is used, this effectively limits log4j 1.2 to handlng only one logging request at a time.

Core classes in log4j 2.0 should not depend on external synchronization for thread safety.
Immutable classes should be preferred in the logging pipeline.
Class attributes (aka @Immutable and @ThreadSafe) should be used to document thread-safety.

In Log4j 2 the core components are designed to be immutable and thread safe. However, annotations aren't being used since everything is expected to work that way. I'm going to mark this as resolved, however feel free to reopen this if you believe more needs to be done.

Ralph Goers
added a comment - 30/Apr/12 08:43 In Log4j 2 the core components are designed to be immutable and thread safe. However, annotations aren't being used since everything is expected to work that way. I'm going to mark this as resolved, however feel free to reopen this if you believe more needs to be done.