使用独立ClassLoader助力Java垃圾回收是否具备优势？

问题背景 #

假设一个Java库包含初始化代码（而非运行时代码），这些初始化代码中定义了大量带选项表菜单的类。应用运行期间，初始化代码仅会被偶尔调用，用于执行修改配置属性等任务。

给出的实现代码如下：

public class Setup
{
    private static final class SetupClassLoader extends ClassLoader
    {   
        SetupClassLoader()
        {   
            super(Setup.class.getClassLoader());
        }   
    }   
    public static Setup getInstance() throws Exception
    {   
        SetupClassLoader scl = new SetupClassLoader();
        Class sc = scl.loadClass("com.example.Setup");
        return (Setup)sc.newInstance();
    }
    private ObjectWithLargeTablesOfData createObjectWithLargeTablesOfData()
    {
        // 实现省略
    }
}

该代码的设计思路是：当Setup实例不再被引用时，由于自定义ClassLoader可被回收，垃圾回收器能更高效地释放其加载的所有资源。

代码是否具备使用价值？ #

这段代码确实有针对性的使用价值，但要结合实际场景权衡：

• 核心价值：它通过自定义ClassLoader实现了类的按需加载与卸载。每次获取Setup实例时，都会用新的SetupClassLoader加载类，当Setup实例和对应的ClassLoader都无引用时，JVM可以回收这个ClassLoader加载的所有类（包括那些携带大选项表数据的ObjectWithLargeTablesOfData类），避免这类占内存的类长期驻留，适合初始化代码调用频率极低、且相关类内存占用大的场景。
• 局限性：每次调用getInstance()都会触发类的重新加载与实例化，会带来额外的类加载开销；另外必须确保自定义ClassLoader没有被意外持有引用（比如静态变量、线程上下文等），否则ClassLoader无法被回收，内存释放的目标就无法达成。

不采用该方式，初始化类是否会长期驻留内存？ #

是的。如果使用系统默认的应用类加载器加载Setup及相关初始化类，这些类的定义会长期驻留内存，直到整个应用进程停止。因为JVM中类的生命周期与加载它的ClassLoader绑定：只要ClassLoader还存活，它加载的类就无法被卸载；而应用类加载器通常伴随应用的整个生命周期，所以哪怕初始化代码只用过一两次，这些带大选项表的类也会一直占用内存。

内容的提问来源于stack exchange，提问作者squarewav