PermGen 空间错误 - Glassfish Server
我正在使用 Hibernate 和 glassfish Server 运行 java web 应用程序。 我收到
在部署多次后，
java.lang.OutOfMemoryError: PermGen space 异常。我在环境变量中尝试了 -XX:MaxPermSize=128M ，但它不起作用。
I am running java web application using Hibernate and glassfish Server. I am getting
java.lang.OutOfMemoryError: PermGen space exception when after I deploying it several times.
I tried -XX:MaxPermSize=128M in my Environment variables, but it doesn't work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
要解决此问题（在基于 Linux 的操作系统中），请执行以下操作
中配置“domain.xml”来增加内存（以便此问题不会经常出现）
1) 通过在/glassfish/domain/domain1/config
搜索
将其设置为更高的值，例如 - 198m 或 256m2) 杀死 glassfish释放正在运行的端口的进程（在我的例子中是 8686）
打开终端（在基于 Linux 的操作系统中）并输入 -
sudo netstat -npl | grep 8686这将导致类似..
tcp6 0 0 :::8686 :::* LISTEN 3452/java接下来使用
kill -9 3452来杀死该进程（在本例中为 3452）现在尝试启动 glassfish，它应该启动。
To solve this problem ( in linux based os ) do following
1) increase memory (so that this problem don't come frequently ) by configuring "domain.xml" in
/glassfish/domain/domain1/config
search for
<jvm-options>-XX:MaxPermSize=set it to higher value eg- 198m or 256m2) kill the glassfish process to free the port on which it was running ( in my case it was 8686)
open terminal (in linux based os) and type -
sudo netstat -npl | grep 8686this will result in something like..
tcp6 0 0 :::8686 :::* LISTEN 3452/javanext use
kill -9 3452to kill that process ( 3452 in this case )Now try to start glassfish, it should start.
这是类加载器内存泄漏。每次重新部署应用程序时，都会为其创建一个新的类加载器，并再次加载应用程序的所有类。这会消耗永久代空间中的内存。
旧的类加载器及其加载的所有类都必须进行垃圾收集，否则在多次部署后最终会遇到 PermGen 空间 OOME。如果外部类加载器加载的对象持有对旧类加载器加载的任何对象的引用，则此方法不起作用。 这篇文章很好地解释了这个问题。
一般来说，类加载器泄漏很难分析，有时也很难修复。
要找出为什么旧的类加载器没有被垃圾收集，您必须使用分析器。在 JProfiler 中，使用堆遍历器，选择 glassfish 类加载器对象并使用传入引用视图检查垃圾收集器根的路径。
类加载器类称为 org.apache.servlet.jasper.JasperLoader。这是常规情况的屏幕截图，其中类加载器仅由加载对象的实时实例保存。
在您的情况下，您应该看到来自外部对象的引用。 Web 容器中类加载器泄漏的另一个常见原因是后台线程未停止。例如 Google Guice 在 3.0 中就有这样的 bug。
（免责声明：我公司开发JProfiler）
This is class loader memory leak. Each time you redeploy the application, a new classloader is created for it and all classes of your application are loaded again. This consumes memory in the perm gen space.
The old classloader and all its loaded classes have to be garbage collected, otherwise you will eventually run into a PermGen space OOME after deploying multiple times. This does not work if an object loaded by an outside classloader holds a reference to any object loaded by the old classloader. This article gives a good explanation of the problem.
Generally, classloader leaks are difficult to analyze and sometimes difficult to fix.
To find out why the old classloaders are not garbage collected, you have to use a profiler. In JProfiler, use the heap walker, select the glassfish classloader objects and use the incoming references view to check for paths to garbage collector roots.
The class loader class is called
org.apache.servlet.jasper.JasperLoader. Here's a screenshot of a regular situation, where the class loader is only held by live instances of loaded objects.In your situation, you should see references from outside objects. Another common cause of a classloader leak in web containers is a background thread that is not stopped. Google Guice for example has such a bug in 3.0.
(Disclaimer: my company develops JProfiler)
如果您使用的是 Windows，请尝试使用任务管理器终止 glassfish 进程 (java.exe *32)，然后重新启动服务器。
If you are using Windows, try killing the glassfish process (java.exe *32) with Task Manager and then restarting the server.
这个问题在迭代部署中多次发生。我已经遇到过很多次了。请参阅以下 JIRA 链接了解 glassfish 错误：
http://java.net/jira/browse/ GLASSFISH-587
This issue happens with iterative deployment many times. I have faced this many times. Please refer the below JIRA link for glassfish bug:
http://java.net/jira/browse/GLASSFISH-587