关于类加载器内存泄露的分析

从上个世纪90年代Java诞生之日起，Java的类和资源的加载就一直是个问题。由于它增加了启动和初始化时间，因此这个问题在Java应用服务器上则尤为明显。为了缓解这个问题，大家试过了不同的访问，比如说以exploaded方式部署，但这只对简单的应用有效；还有2001年发明的Java热插拔的机制。启用热插拔的话，你在一个现有的方法内的改动马上就会生效。由于方法的边界限制，这个方法并不是特别有用，通常它只是在调试的阶段使用。对于现在的应用来说，编译，部署以及重启，等待个5到15分钟已经不是什么稀奇事儿了。越大型的应用服务器，这种情况可能就越明显。

存在的问题
一旦某个Java类被类加载器加载了，它就是不可变的，只要类加载器还存在，它也会一直存在下去。类的唯一标识是它的类名以及类加载器的标识，要重启一个应用的话，你需要创建一个新的类加载器，并加载最新版本的类。你不能把一个已经存在的对象映射到一个新类上面，因此重新加载时的状态迁移非常重要。这意味着你得初始化应用和配置的状态，拷贝用户的会话信息，以便重新生成整个应用的对象图。通常来说这非常耗时并很容易产生内存泄露。

说到类加载器的内存泄露，由于Java使用的内存模型的原因，哪怕是一小行代码的泄露都会产生很大的影响。比如说，一个类加载器的实例，它拥有自己加载的所有类的引用，以及这些类生成的所有对象的引用。因此在应用重启过程的状态迁移中，哪怕一个很小的泄露，都可能会产生极大的影响。

那这些对开发人员来说意味着什么？它意味即使是普通的编译，构建，打包，部署，应用重启，这些琐事都会极大的分散你的注意力，影响你的开发效率。

本文试图揭秘对开发人员而言JRebe