Skip to content
This repository has been archived by the owner on Mar 14, 2019. It is now read-only.

关于自定义classloader加载的问题 #43

Open
jht5945 opened this issue Jun 16, 2012 · 2 comments
Open

关于自定义classloader加载的问题 #43

jht5945 opened this issue Jun 16, 2012 · 2 comments

Comments

@jht5945
Copy link

jht5945 commented Jun 16, 2012

在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
Copy link
Member

zhongl commented Jun 16, 2012

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

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

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

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

@jht5945
Copy link
Author

jht5945 commented Jun 16, 2012

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants