Many of the ThreadLocals were added in the effort to make much of Log4j be garbage free. As I recall Remko did some performance tests on various alternatives and what we have is a result of that. But that is just my recollection.
Ralph > On Dec 28, 2019, at 2:39 PM, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > Regarding log4j2.enableThreadlocals configuration knob, it feels more > like a hint rather than a hard restriction. See how > AbstractStringLayout#getStringBuilder() doesn't take that flag into > account. > > On Sat, Dec 28, 2019 at 10:10 PM Volkan Yazıcı <volkan.yaz...@gmail.com> > wrote: >> >> Hello, >> >> I see that many Log4j components rely on TLA for efficiency reasons. >> There I have two main concerns: >> >> 1. TLAs, for obvious reasons, entail an extra memory cost on >> threads, particularly, even when they are not used. Consider >> a thread invoking a Log4j flow where various TLAs are >> performed. That storage will keep on occupying the memory >> until the next time it gets used. >> >> 2. JEE servers are known to accommodate quite some threads, >> e.g., the the default thread count is 200 for Tomcat[1]. TLAs at >> will will certainly have an impact on context switching costs too. >> >> Is there a convention recommended in this domain? In >> log4j2-logstash-layout, I favor object pools over TLAs. Object pools >> offer better memory utilization with the cost of synchronization. I >> see that many text-based Log4j 2.0 layouts rely on >> ThreadLocal<StringBuilder>s. While it performs pretty good, I am >> struggling with the idea of associating a large(?) text chunk next to >> each thread who has at least once attempted to log something. >> >> Best. >> >> [1] >> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Common_Attributes >
