[
https://issues.apache.org/jira/browse/HADOOP-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307238#comment-14307238
]
Lukáš Karas commented on HADOOP-10513:
--------------------------------------
as a workaround, method can be called with reflection...
Method clearCacheMethod =
ReflectionUtils.class.getDeclaredMethod("clearCache");
if (clearCacheMethod != null) {
clearCacheMethod.setAccessible(true) ;
clearCacheMethod.invoke(null) ;
}
> ReflectionUtils::CONSTRUCTOR_CACHE leaks class loaders
> ------------------------------------------------------
>
> Key: HADOOP-10513
> URL: https://issues.apache.org/jira/browse/HADOOP-10513
> Project: Hadoop Common
> Issue Type: Bug
> Components: util
> Affects Versions: 2.4.0
> Reporter: Gopal V
> Labels: leak, permgen
> Attachments: class-loader-leak.png
>
>
> Any code which uses custom class-loaders needs to be aware of the
> ReflectionUtils::CONSTRUCTOR_CACHE
> {code}
> /**
> * Cache of constructors for each class. Pins the classes so they
> * can't be garbage collected until ReflectionUtils can be collected.
> */
> private static final Map<Class<?>, Constructor<?>> CONSTRUCTOR_CACHE =
> new ConcurrentHashMap<Class<?>, Constructor<?>>();
> {code}
> This is not a problem when using only 1 AppClassLoader.
> But in cases where the application uses multiple classloaders (to isolate
> UDFs), this holds onto class references and their associated class loaders by
> ref (& that leaks all the statics).
> The clear method for this cache is unfortunately marked only for testing.
> {code}
> // methods to support testing
> static void clearCache() {
> CONSTRUCTOR_CACHE.clear();
> }
> {code}
> The cache shows up as the only reference for the class loaders.
> !class-loader-leak.png!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
