我可以阻止 java.util.logging 造成内存泄漏吗？
停止我的网络应用程序后，大量 PermGen 没有被释放。罪魁祸首似乎是 WebappClassLoader（在 Tomcat 中，但它也发生在 Jetty 中），它通过来自一堆其他对象的引用保存在内存中。下图显示了引用 WebappClassLoader 的对象以及引用它们的事物等等。
其中一个粘性对象似乎是 net.lag.logging.Level$INFO$ 的实例，其引用存储在 java.util.logging.Level 的静态 known 数组中。
看来 java.util.logging.Level 保留了对其自身所有实例的静态引用。糟糕、令人讨厌的java.util.logging.Level！我能做点什么吗？ java.util.logging 框架由第三方库使用，因此我认为我没有不使用它的选择。
After stopping my web app, a significant amount of PermGen is not being released. The culprit seems to be the WebappClassLoader (in Tomcat, but it happens in Jetty too), which is kept in memory by references from a bunch of other objects. The following image shows that objects that refer to WebappClassLoader, and the things that refer to them, and so on.
One of the clingy objects seems to be an instance of net.lag.logging.Level$INFO$, to which a reference is stored in the static known array in java.util.logging.Level.
It appears that java.util.logging.Level keeps a static reference to all instances of itself. Bad, nasty java.util.logging.Level! Can I do anything about it? The java.util.logging framework is used by a third-party library, so I don't think I have the option of not using it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除了让 Sun 修复 Level 实现或更改库以消除其自定义 Level 之外，我能想到的唯一方法是将库从 Web 应用程序类加载器移出并移入容器（共享或公共类加载器）。
如果执行此操作，仍然会有 Level 的自定义实例，但它们将不再链接到 Web 应用程序。这样，如果您弹回网络应用程序，它将继续回收相同的关卡（不会泄漏新的关卡）。
当然，这会影响库的类加载器，并且可能会损坏。有些东西需要在 Web 应用程序中，不能移动到容器中。即使该库继续工作，它本身也可能保留对 Web 应用程序其他部分的类似引用，这将再次出现完全相同的问题。不过，还是尝试一下吧。
Short of making Sun fix the Level implementation or changing your library to do away with its custom Level, the only way I can think of is moving the library out of the web application classloader and into the container (shared or common classloader).
If you do this, there will still be the custom instances of Level, but they will no longer be linked to the web application. So that if you bounce the webapp, it will keep recycling the same Levels (not leaking new ones).
Of course, this will affect the classloader for the library, and it might break. Some things need to be in the web application and cannot be moved to the container. Even if the library continues to work, it might itself keep similar references to other parts of the web application around, which would be the exact same problem again. Still, give it a try.