是什么让热门部署成为"难题"？

在工作中,我们遇到了" PermGen内存不足 "异常的问题,团队领导决定它是JVM中的一个错误 - 与代码的热部署有关.在没有解释许多细节的情况下,他指出热部署是一个"难题",即使.NET还没有这么做也很难.

我从鸟瞰图中发现了很多解释热部署的文章,但总是缺乏技术细节.有人能指出我的技术解释,并解释为什么热部署是"一个难题"？

加载类时,有关该类的各种静态数据存储在PermGen中.只要存在对此Class实例的实时引用,就不能对类实例进行垃圾回收.

我认为问题的一部分与GC是否应该从perm gen中删除旧的Class实例有关.通常,每次热部署时,都会将新的类实例添加到PermGen内存池中,而现在未使用的旧实例通常不会被删除.默认情况下,Sun JVM不会在PermGen中运行垃圾收集,但可以使用可选的"java"命令参数启用它.

因此,如果您热部署足够多次,最终将耗尽您的PermGen空间.

如果你的web应用程序不会关闭完全取消部署时-如果它留下一个线程中运行,例如-那么所有由该Web应用程序使用的类的实例将在PermGen的空间被固定.您重新部署,现在将所有这些Class实例的另一个完整副本加载到PermGen中.你取消部署并且Thread继续运行,在PermGen中固定另一组类实例.您重新部署并加载了一整套复制副本......最终您的PermGen填满了.

你有时可以解决这个问题:

向最近的Sun JVM提供命令参数,以在PermGen和类中启用GC.那是: -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

使用不使用固定大小的PermGen或在加载的类上执行GC的其他JVM

但这只有在您的Web应用程序完全干净地关闭时才会有所帮助,不会对该Web应用程序的类加载器加载的任何类的任何类实例保留实时引用.

由于类加载器泄漏,即使这样也不一定能解决问题.(在某些情况下,还有太多的实习字符串.)

查看以下链接了解更多信息(两个粗体的图表有很好的图表来说明部分问题).

类加载器泄漏:可怕的"java.lang.OutOfMemoryError:PermGen space"异常

未知世代:彼尔姆

介绍永久性一代

Tomcat Wiki:如何处理内存不足错误

一般而言,问题是Java的安全模型,它实际上试图阻止再次加载已经加载的类.

当然Java从一开始就支持动态类加载,类重新加载很困难.

认为正在运行的java应用程序注入了带有恶意代码的新类是有害的(并且有充分理由).例如,来自互联网的java.lang.String破解实现,而不是创建字符串,删除一些随机文件hile调用方法length().

因此,他们构思Java的方式(我认为.NET CLR因此在JVM中受到高度"启发")是为了防止已经加载的类再次加载相同的VM.

他们提供了一种机制来覆盖这个"功能".类加载器,但同样是类加载器的规则,它们应该在尝试加载新类之前请求"父"类加载器的权限,如果父类已经加载了类,则忽略新类.

例如,我使用了从LDAP或RDBMS加载类的类加载器

当应用程序服务器成为Java EE的主流时,热部署成为Java世界的必需品(并且还需要像spring这样的微容器以避免这种负担).

每次编译后重新启动整个应用服务器会让任何人疯狂.

所以应用服务器提供商,提供这个"自定义"类加载器来帮助热部署,并使用配置文件,这种行为,应该在生产中设置时禁用.但权衡是你必须在开发中使用大量内存.因此,执行此操作的好方法是每3-4次重新启动一次.

对于从一开始设计加载其类的其他语言,就不会发生这种情况.

例如,在Ruby中,您甚至可以向正在运行的类添加方法,在运行时覆盖方法,甚至可以将单个方法添加到唯一的特定对象.

在这些环境中的权衡当然是记忆和速度.

我希望这有帮助.

编辑

我前段时间发现这个产品,承诺重新加载尽可能简单.当我第一次写这个答案时,我不记得这个链接了.

它是ZeroTurnaround的JavaRebel