[ 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)