[
https://issues.apache.org/jira/browse/LOG4J2-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733315#comment-16733315
]
Ralph Goers commented on LOG4J2-2490:
-------------------------------------
Gary, in addition to fixing the locking issue we also need to improve the
overall performance of printing the stack trace. ThrowableProxy currently
maintains a cache of the current stacktrace's classes. A user ran a benchmark
that showed significant improvement when they are permanently cached. However,
the cache currently contains the ClassLoader. We shouldn't store that in
anything stored permanently.
> thread blocked when logging numerous exception stack
> -----------------------------------------------------
>
> Key: LOG4J2-2490
> URL: https://issues.apache.org/jira/browse/LOG4J2-2490
> Project: Log4j 2
> Issue Type: Improvement
> Components: Servers
> Affects Versions: 2.7
> Reporter: Payne Xu
> Priority: Major
>
> many thread blocked when logging a lot of exception, I found the reason is a
> java optimize to reflection.
> {quote}The first 15 runs (by default) of your reflected method is called
> using JNI; after that, bytecode is generated and calling that reflected
> method would perform identically to calling that method directly in Java code.
> {quote}
> ThrowableProxy.toExtendedStackTrace, the method will load class, and get jar
> package info, when it process a optimized reflected method, it will use
> classloaders but never found the class such as
> _sun.reflect.GeneratedMethodAccessor119, in this process_ it will try to
> load class from jar file every time and spend so much cost. Worse, have a
> lock when loadClass, when many threads run this method, thread blocked.
>
> here is a article detailed this problem:
> https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=https%3A%2F%2Fblog.fliaping.com%2Fa-high-concurrency-problem-of-log4j2%2F
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
