我正在使用Byte Buddy,在这种情况下,我可能需要用它创建几十万个类。这些是实现接口的独立类,而不是代理。
现在,我通过包装应用程序的一个类加载器将我的实例加载到类加载器中:DynamicType.Unloaded<?>
final Class<?> myClass =
unloadedType
.load(someAppClassLoader, ClassLoadingStrategy.Default.WRAPPER)
.getLoaded();
这种包装策略适合我,但我遇到的问题是,每次我执行上面的代码时,都会创建一个仅包含新类的新密封。我知道我可以“包括”辅助类型...但这些不是辅助类型,而是完全独立的类。ClassLoader
由于我必须创建数千个类加载器,因此我留下了大量我并不真正需要的类加载器,因为我想将bytebuddy创建的类与其余类隔离开来,但不是一个类,也不需要为每个类加载器创建一个新的类加载器。我的分析显示,大量类加载器(在本例中相当重)带来了相当大的内存开销。
从我的测试中,我似乎可以对第一个使用包装策略:
final Class<?> myClass =
type
.load(someAppClassLoader, ClassLoadingStrategy.Default.WRAPPER)
.getLoaded();
...然后检索新的类装入器:
final ClassLoader bbClassLoader = myClass.getClassLoader();
...然后在后续创建中使用此类装入器,方法是将策略切换到注入:
final Class<?> myOtherClass =
otherUnloadedType
.load(bbClassLoader, ClassLoadingStrategy.Default.INJECTION)
.getLoaded();
但这对我来说看起来不是一个干净的策略,因为它似乎是通过内省注入的,以规避类加载器被密封的事实。所以我想知道是否有更好的机制在Byte Buddy中做到这一点。
请注意,为了有一个正确密封的类装入器,我可以一次将我所有的数千个对象变成一个类装入器实例(并密封它)。我可以在应用程序引导时批量初始化我的所有类,然后不用进一步动态创建类加载器。DynamicType.UnloadedClass<?>
对于像我这样的场景,正确的策略是什么?
猛跑小猪
相关分类