Log4j2 is the evolution not only to Log4j but also to Logback, as it takes Logback’s feature one step forward.

The main selling point is the improved performance, throughput of messages and latency, which apparently is a huge leap forward compared to Log4j and also Logback.

Other interesting Log4j2 features are:

• Automatic reloading of logging configurations
• Property Support: Log4j2 loads the system’s properties and they can be evaluated even at the configuration level
• Java8 lambdas and lazy evaluation: It provides an API for wrapping a log message inside a lambda statement, which only gets evaluated if truly needed
• Garbage free: An interesting architectural feature, as Log4j2 has no or very little (in case of web apps) garbage. You can read more about that here.
• Async loggers using the LMAX Disruptor: The disruptor is a very interesting technology and it is always provoking to examine use cases of it being used in strain

I played around with Log4j2 and in general i was very happy with its API, implementation ( it actually separates the API from the implementation, even though that means the developer needs to add 2 maven dependencies), configuration simplicity and finally the performance.

Even though measuring a logger’s performance with JMH is not advisable i tried to compare its performance (using async and sync loggers) against the old Log4j. The performance (average time and throughput) was indeed better and at the edge cases 15K ops/ms faster!. Having said that, you should take that with a pinch of salt, because as mentioned earlier JMH is not the right tool to performance measure and compare the two logging implementation.

For reference the simple java program used to perform the various tests can be found in Github.

Some indicative results, performing 3 runs for each logger can be seen below.