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
