我知道之前可能已经多次询问过了,但我还没有看到它的实际修复。
我的日常开发环境如下: 1. NetBeans(最新),2。Glassfish(最新与NB捆绑在一起),3。JPA,JSF,JAXB,泽西为JAX-RS
我的项目中有大约600个类,分布在两个EJB项目和一个WAR项目中,都在EAR中。
我在最新的JDK 7(在OS X上),我每小时都会得到臭名昭着的“PermGen space”错误。让我们说如果我正在进行3次增量重新部署,我只能在之前工作一段时间:
通常唯一的解决方案是每30分钟左右杀死一次玻璃鱼。这肯定是由于某个地方的错误只是为每个新的增量重新部署加载新类而不是摆脱旧的。我认为这应该在JDK 7中修复?
在这种开发环境中,这是一个长期存在的错误,我感到震惊的是,在我5年多的Java开发之后它仍然存在。这太令人沮丧,而且非常无益。
(就在任何人建议增加permgen空间之前,请相信我,我已经尝试过了,它唯一能解决的是延长不可避免的时间。我看到重新部署需要400个最糟糕的几秒钟。对于这样大小的项目,重新部署应该需要5-6秒。不会更多。)
编辑:在执行以下步骤后,我在Glassfish流程上运行了jmap和jhat:
事实证明我的所有类(应该已经卸载)仍然被加载!希望这对于阅读此内容的人来说是有用的信息...
答案 0 :(得分:3)
当然,这是一个错误,我认为没有一个简单的解决方案。 (如果有,可能你已经有了它。)
您可以尝试的方法:使用一些热门代码替换工具,例如JRebel
,这样您就不必一直部署,而是使用此工具监视更改.class
个文件(甚至是其他Web资源,如果您这样配置),替换正在运行的JVM中的类定义 。听起来很酷,对吧?
它作为 Java代理运行,它在JVM启动时启动。
此解决方案有3个缺点:部署速度稍慢,调试更难,而且它是专有软件(但成本不高)
答案 1 :(得分:0)
使用Netbeans + Glassfish进行开发并使用“部署保存”时,我们发现在重新部署项目时,应用程序中打包的库不会被卸载;这会导致GF减速并迅速耗尽内存。
尝试为所有编译时库取消选择“Package”,并将那些尚未在Glassfish类路径中的那些放在domainX / lib目录中。
不确定,但这可能与GLASSFISH-17449或GLASSFISH-16283有关。