Simple Grails 2.5.1应用程序泄漏带有Groovy 2.4.4的类加载器
我在Tomcat 8中热重新部署简单的Grails应用程序时遇到问题。
我的设置如下：
- Grails 2.5.1全新的应用程序，刚刚使用
create-app创建
- Tomcat 8.0.28（64位Linux二进制版本）
- Java1.80_65-b17 HotSpot服务器VM
Tomcat也是一个全新的安装，只修改了两件事（因为我想在生产中使用它们）：
服务器xml
上下文xml
我重启了Tomcat服务器。据JVisualVM称，它加载了2398个类。复制grails prod war生成的war文件后，等待部署完成，它加载了10 022个类。在再次复制战争，从而引发重新部署后，它有16300个班级。
我在第一次部署后进行了堆转储，第二次，并使用eclipse MAT分析类加载器，我可以看到有一个额外的org.apache.catalina.loader.WebappClassLoader加载了6 138个类（所以总共有两个）。
堆空间保持不变，只是元空间的使用量显著增加（与类的数量的增长率大致相同）。
使现代化
使用MAT进行更深入的挖掘，我注意到总有9个实例使类加载器保持活动状态。它们是org的实例。科德豪斯。棒极了。反射ClassInfo（每个基本java类型包装器和Void）各一个。这些ClassInfo仅由java引用。lang.ClassValue$Entry，它扩展了WeakReference，所以我真的很困惑这些实例怎么没有被垃圾收集。
有人有过类似的问题吗？是什么原因导致装载机在附近徘徊？
共有1个答案
这个问题与https://issues.apache.org/jira/browse/GROOVY-7591
我不完全理解这个问题，但我将尝试简短地描述它：
使用ClassValue（由于JDK错误）可以防止对象被垃圾收集。Groovy 2.4.5中的提交暂时禁用了ClassValue的使用，而JDK错误得到修复。
Grails 2.5.1默认使用groovy 2.4.4，所以为了解决这个问题，我在BuildConfig中替换了它。groovy，并重建了应用程序。
build 'org.codehaus.groovy:groovy-all:2.4.5'
compile 'org.codehaus.groovy:groovy-all:2.4.5'
-
问题内容： 我在Glassfish上部署了一个应用程序。随着时间的流逝，加载的类的数量攀升至数百万，而我的表现似乎正在上升。 为了帮助排除故障，我在jvm参数中添加了以下内容。-XX：+ PrintGCDetails -XX：+ TraceClassUnloading -XX：+ TraceClassLoading 现在，当观看输出时，我看到相同的类一遍又一遍地加载。基本上，每次调用Web服务并且
-
问题内容： 我最近开始分析我使用VisualVM编写的osgi Java应用程序。我注意到的一件事是，当应用程序开始（通过JMS）向客户端发送数据时，已加载类的数量开始以稳定的速度增加。但是，堆大小和PermGen大小保持不变。即使停止发送数据，类的数量也永远不会减少。这是内存泄漏吗？我认为是这样，因为已加载的类必须存储在某个位置，但是即使我将应用程序运行了几个小时，堆和permgen也不会增加。
-
问题内容： 昨天，我将第一个Grails（2.3.6）应用程序部署到开发服务器并开始对其进行监视。我刚得到一个自动监视器，指出CPU已固定在这台计算机上，因此我通过SSH进入了它。我跑去，发现固定服务器的是我的Java应用程序的PID。我还注意到内存为40％。几秒钟后，CPU停止固定，下降到正常水平，内存下降到〜20％范围。经典大型GC。 在收集时，我进行了堆转储。GC之后，然后我在JVisual
-
我在做java企业应用。该应用程序后端有hibernate框架。由于应用程序中最近的更改，一些代码消耗了weblogic server中的所有JDBC连接池。 应用程序连接是在代码中进行属性处理，对于每个线程，我们使用threadlocal类创建每个会话。所以创建连接没有问题。该应用程序已存在5年以上。 我们怀疑最近的代码更改会导致此主要问题。最后，我们决定使用探查器工具来调查此问题。 在此之前，
-
我有一个运行在Tomcat7上的Java web应用程序出现内存泄漏。在负载下（使用JConsole确定），应用程序的平均内存使用量随时间线性增加。在内存使用达到稳定期后，性能会显著下降。响应时间从大约100ms到[300ms,2500ms]，所以这实际上导致了真正的问题。 使用VisualVM，我看到至少一半的内存被字符数组（即char[])使用，而且大多数字符串（每个实例的数量大致相同，为30
-
我看到了这个Python问题：应用引擎延迟：跟踪内存泄漏 ...同样，我也遇到了这个可怕的错误： 在为总共384个请求提供服务后，超过了128 MB的软专用内存限制 ... 处理此请求后，发现处理此请求的进程占用了太多内存，因此被终止。这可能会导致应用程序的下一个请求使用新进程。如果经常看到此消息，则应用程序中可能存在内存泄漏。 根据另一个问题，可能是“实例类”太小，无法运行这个应用程序，但是在增