重温java之classloader体系结构（含hotswap）

重载类也有很多问题不能解决
比如如果修改的部分恰好是能影响 其他类初始状态 的方法，那简单的替换类还不行，还必须重新执行此方法才可以。如Context listener部分。

热替换肯定不能是完全自由的，肯定会有相当的限制。这样的问题应该在架构的层面上解决，直接规定哪些类能够被热替换。或许还要限制类被调用的方法，还要禁止用户自己实现classloader....

这个问题我也在研究

热替换只能帮助提高开发与调试效率， 使用者应该明白它的职责。

像你说的，改了初始化部分， 其实对于热替换来说， 任务已经完成了， 你只要自己再触发
一遍初始化逻辑，就可以。
（类似这种问题， 比如测试一个beanFactory的初始化， 改了初始化逻辑， 只能每次都一路跑到底， 没办法的）

另外， 像拦截所有访问这种热替换方式， 经过我测试， 已经可以覆盖大部分业务使用场景了。

如果有兴趣， 我们可以一起研究下javarebel。它的功能很强。

最近我也在研究javarebel，有些心得，可以一起研究一下

这个东西对开发效率的提升太明显了，很有价值啊

在应用服务器上直接替换类服务器自动重新加载是不是用了楼主得方法？

这个... Reload 很困难吗? 我们按照 thinkbase.net 这篇文章 上面的例子自己做过一个, 很好用啊, 也不觉得实现起来很复杂;

当然这个东西有其固有的性能损耗(主观想像, 没测试过), 反正我们只在开发阶段使用, 生产环境是禁止掉的.

楼上很多说法是有道理的, 这个东西我们不是用在整个系统范围的, 事实上, 我们的核心代码并不使用 reload, 只是业务代码(一般都是实现了核心定义的某个接口的, 比如那些 Action/Handler/Listener 等)被核心以自定义的 ClassLoader 加载, 也就可以 Reload 了, 当然这些类要么是无状态的, 要么是在每次请求的时候重新 new 出来的, (不过, 业务系统开发中修改调试最多的也就是这些代码, 不是吗? :P), 因此, 大部分情况下就不存在需要初始化之类的问题了.

TO：楼上
仁兄是从reload jar来实现的，跟reload class还是一点区别。
另外，AS里要做到reload，不hack掉class，会受到CLASSLOADER的限制

javarebel的确是个好东西,但是用这个东西需要一系列的配合的.
比如我们如果有用Guice这样的基于注解的IOC的话,如果改变了
这样的配置元数据,就要求IOC做出相应的反应(估计在下一个
版本的Guice中可以看到这样的支持).
这里侦听Class的改动是一个方面,对这个改动作出合适的反应
更加是一个重要的不可或缺的方面.

当然了,这开发模式下面我们可以不做缓存,尽量避免对Reload不友好
的Class部分进行改动.大不了就Restart吗.

用过javassist吗，他可以内存中实现动态创建，修改类，并且可以直接new instance()直接用，可以写一个接口，然后动态的重写，创建这个接口的实现，但有一点，这个工具对于实际的硬盘上的.class文件只能修改一次，不能多次重复修改

即当前类是由自身classLoader加载的， 而内部依赖的类还是老对象的classLoader加载的.

if (null != super.findLoadedClass(name))
            return reload(name, resolve);

这个实现的代码能否解释一下？