[
https://issues.apache.org/jira/browse/LOG4J2-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936463#comment-14936463
]
Dmitri Blinov commented on LOG4J2-1125:
---------------------------------------
As it was reasonably pointed out in
[http://stackoverflow.com/questions/3869026/how-to-clean-up-threadlocals/3869236#3869236]
{quote}
if you make the mistake of creating a new ThreadLocal instances over and over
again (instead of using a static variable to hold a singleton instance), the
thread local values won't get overwritten, and will accumulate in each thread's
threadlocals map. This could result in a serious leak.
{quote}
For me the main problem with cleaning up threadlocals is that it's only
possible from the thread itself by calling threadlocal.remove() method, or by
respawning the thread itself. If we are trying to achieve a perfomance
improvement by merely caching instances of some class, there are known ways for
this like pooling. For instance we can look at the tomcat's PageContext
pooling. It has nothing to do with threadlocals.
> Reuse StringBuilder to improve performance for PatternLayout
> ------------------------------------------------------------
>
> Key: LOG4J2-1125
> URL: https://issues.apache.org/jira/browse/LOG4J2-1125
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Affects Versions: 2.3
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.4
>
>
> As part of the investigation for LOG4J2-930 (PatternLayout performance), I
> found that in PatternLayout.toSerializable(), instead of creating a new
> StringBuilder each time this method is called, caching and reusing a
> ThreadLocal<StringBuilder> makes a huge difference in performance.
> *Before (new StringBuilder instance for each event)*
> {code}
> Benchmark Mode Samples
> Score Error Units
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 125646
> 1413.362 ± 33.806 ns/op
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 128680
> 1383.201 ± 33.076 ns/op
> {code}
> *After (reuse ThreadLocal<StringBuilder>)*
> {code}
> Benchmark Mode Samples
> Score Error Units
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 156816
> 1138.547 ± 20.290 ns/op
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 127978
> 1355.166 ± 19.462 ns/op
> {code}
> org.apache.logging.log4j.PerformanceComparison results indicate this improves
> overall performance:
> *Before (new StringBuilder instance for each event)*
> {code}
> Log4j : 1501
> Logback : 1208
> Log4j 2.0: 1646
> ###############################################
> Log4j : 1487
> Logback : 1165
> Log4j 2.0: 1566
> ###############################################
> Log4j : 1490
> Logback : 1170
> Log4j 2.0: 1485
> ###############################################
> Log4j : 1392
> Logback : 1143
> Log4j 2.0: 1629
> {code}
> *After (reuse ThreadLocal<StringBuilder>)*
> {code}
> Log4j : 1498
> Logback : 1202
> Log4j 2.0: 1213
> ###############################################
> Log4j : 1394
> Logback : 1057
> Log4j 2.0: 1290
> ###############################################
> Log4j : 1240
> Logback : 1109
> Log4j 2.0: 1335
> ###############################################
> Log4j : 1310
> Logback : 1146
> Log4j 2.0: 1210
> {code}
> There are more changes for LOG4J2-930, so I am splitting off this item into a
> separate ticket so I can address it and close it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
