重新部署时是否仍然无法摆脱 PermgenSpace 异常?

发布于 2024-09-27 07:01:14 字数 234 浏览 0 评论 0原文

这是我一直遇到的一个老问题。我想在开发环境中重新部署。经过一些部署后,我用完了 permgen,不得不终止服务器。几年前,我试图找到问题的解决方案,但只是发现 Spring 和 Hibernate 互相指责对方造成了这个问题。有找到解决办法吗?

Spring Roo 声称它不会在运行时生成类,因此这不会成为问题。它真的有效吗?如果有效,我该如何配置我的应用程序?

我意识到这里有两个问题,但如果你能回答一个就足够了:)

This is an old problem I've always had. I want to redeploy in development environment. After some deployments I run out of permgen and have to kill the server. Years ago I tried to find a solution to the problem but just found Spring and Hibernate blaming each other for the problem. Has any solution been found?

Spring Roo claims it doesn't generate classes at runtime so it wouldn't be a problem. Does it really work and if it does, how can I configure my application like that?

I realize there are two questions here but if you can answer one it is enough :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

南风起 2024-10-04 07:01:14

据我了解,典型的 PermGen 存储泄漏是这样的。

  1. 某处存在对其类已被热部署替换的某个对象的可到达引用。

  2. 该对象具有对其类描述符的引用。

  3. 类描述符具有对其类加载器的引用。

  4. ClassLoader 具有对其已加载的所有类的类描述符的引用。

  5. 每个类描述符都具有对类静态框架、其字节码、其本机代码等的引用。

仅对一个对象的一次引用就足以导致永久生成泄漏。如果可能是一个枚举值,一个尚未注销的侦听器,...

编辑

遇到此问题的人采取的正常方法是耸耸肩并增加 PermGen 堆大小。如果您确实需要解决 Web 应用程序的问题,那么:

  • 查看 Web 应用程序关闭的方式,确保数据库连接/连接池已关闭、所有回调均未注册等。
  • 使用 Java 内存探查器来跟踪由重新部署触发的 PermGen(和其他)内存泄漏。
  • 如果随着您的网络应用程序的发展引入新的泄漏,请准备好重复此过程。

我不知道 Hibernate 是否存在特定问题,但任何复杂的框架都可能容易受到此类问题的影响,无论是其本身还是与应用程序代码结合使用。

As far as I understand it, typical PermGen storage leaks go like this.

  1. Somewhere there is a reachable reference to some object whose class has been replaced by a hot deployment.

  2. That object has a reference to its Class descriptor.

  3. The Class descriptor has a reference to its ClassLoader.

  4. The ClassLoader has references to the Class descriptors for all classes that it has loaded.

  5. Each Class descriptors has references to the classes statics frame, its bytecodes, its native code, and so on.

Just one reference to one object is sufficient to cause the permgen leak. If could be an enum value, a listener that hasn't been unregistered, ...

EDIT

The normal approach taken by people who encounter this problem is to shrug their shoulders and increase the PermGen heap size. If you really need to fix the problem for your web application(s), then:

  • Look at the way that your webapp shuts down, making sure that database connections / connection pools are closed, all callbacks are unregistered, etc.
  • Use a Java memory profiler to trace the PermGen (and other) memory leaks triggered by a redeployment.
  • Be prepared to repeat the process if new leaks are introduced as your webapp evolves.

I don't know if there are specific issues with Hibernate, but any complicated framework is potentially susceptible to this kind of problem, either on its own or in combination with application code.

罪#恶を代价 2024-10-04 07:01:14

如果您在 Linux 下运行应用程序,则使用 IBM JRE 运行应用程序将解决此问题。

If you are running your application under linux, running your application with the IBM JRE will solve this issue.

淡淡绿茶香 2024-10-04 07:01:14

有几件事可以帮助解决这个问题。 Spring 有一个“IntrospectionCleanupListener”可以提供一点帮助。如果您要在 Web 应用程序中加载和创建 JDBC 连接,您可以使用 servlet 上下文侦听器来取消注册您在应用程序中加载的驱动程序。这些有帮助,但并不能完全解决问题。

There are a couple of things that can help with this some. Spring has a "IntrospectionCleanupListener" that can help a little. If you are loading and creating JDBC connections within the web app you can have a servlet context listener that will deregister the drivers you loaded in the app. These help, but do not entirely fix the problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文