关于自定义classloader加载的问题

[jht5945]

在rt.jar(或classes.jar)中，包含其它的一个JDK系统中的类有很多不是以java, sun 或 com.sun开始的，也有很多org.w3c开始的，和其它的类；我之前在做单元测试框架的时候也使用过自定义的ClassLoader，最后的解决方法是先遍历了一遍JDK自己的jar包加载到内存，通过hashset判断才解决这个问题，不过这个方法比较耗内存。

但下面判断方法有点欠妥：

if (name.startsWith("java") || name.startsWith("sun") || name.startsWith("com.sun"))

https://github.com/zhongl/HouseMD/blob/master/src/main/scala/com/github/zhongl/housemd/Duck.java

[zhongl]

嗯, 你所言极是, 果然是有眼力的人, 这里确实是个"将就"且"粗暴"的方案.

使用自定义ClassLoader的初衷有两个:

1. 隔离HouseMD依赖(如ASM)与目标进程中存在字节码可能的冲突
2. 使用独立的ClassLoader以便在HouseMD退出之后, 可以在下一次Full GC的时候加载的HouseMD的类可以被回收 -> 不过这个貌似没有起作用, 囧

我在这里征集解决上述问题的最佳解决方案.

[jht5945]

虽然JDK的源代码没有看过，但classloader似乎会增加hotspot的GC负担，我们有一个应用使用了XStream，但使用不当在每次序列化的时候都new了一个XStream的实例，而XStream每个实例都有自己的ClassLoader，所以就悲剧了，程序跑了一段时间后（一般是24小时以后），机器load飙高，最高到40多，但重启后一天又是正常的，非常诡异，查了很多才查出来，原则上FGC如果没问题应该能GC掉，但就事实来说在某些场景下似乎这个对hotspot比较困难，解决方法是将XStream改成单例（因为本身就是线程安全的）就OK了，也就没有动力去研究hotspot了