Ralph is correct. When running in a servlet environment (J2EE), Log4j2 automatically does not use ThreadLocals because of the problems associated with threadpools in those environments. This is documented in the manual: https://logging.apache.org/log4j/2.x/manual/garbagefree.html#Config
In addition, we did some work to ensure that the StringBuilders in ThreadLocals do not grow beyond some configurable maximum size to ensure that memory consumption remains reasonable. I don't remember the reason why AbstractStringLayout#getStringBuilder does not check log4j2.enableThreadlocals. This may be an oversight, I am not sure. I will take another look when I have time. Remko. On Sun, Dec 29, 2019 at 7:27 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 > > > >
