我正在Java 5上编写一个客户端Swing应用程序(图形字体设计器)。最近,我遇到了Java .lang. outofmemoryerror: Java堆空间错误,因为我在内存使用上不保守。用户可以打开无限数量的文件,程序将打开的对象保存在内存中。在快速研究之后,我发现5.0 Java虚拟机和其他人说,在Windows机器上,JVM默认的最大堆大小为64MB。

在这种情况下,我应该如何处理这个约束呢?

我可以使用java的命令行选项增加最大堆大小,但这需要计算出可用的RAM并编写一些启动程序或脚本。此外,增加到某个有限最大值并不能最终摆脱这个问题。

我可以重写一些代码,频繁地将对象持久化到文件系统中(使用数据库也是一样),以释放内存。它可能会起作用,但可能也要做很多工作。

如果你能告诉我上述想法的细节或一些替代方案,如自动虚拟内存,动态扩展堆大小,那将是伟大的。


当前回答

遵循以下步骤:

从tomcat/bin打开catalina.sh。 将JAVA_OPTS更改为 JAVA_OPTS = " -Djava.awt。无头= true -Dfile。encoding=UTF-8 -server -Xms1536m -Xmx1536m -XX:NewSize=256 6m -XX:MaxNewSize=256 6m -XX:PermSize=256 6m - xx: MaxPermSize = 256 - xx: + DisableExplicitGC” 重新启动tomcat

其他回答

是的,使用-Xmx,您可以为JVM配置更多内存。 确保你不会泄露或浪费内存。获取堆转储并使用Eclipse Memory Analyzer分析内存消耗。

默认情况下,JVM对其他性能相关特性使用小尺寸和小配置。但是对于生产环境,您可以调优例如:>(如果仍然没有足够的内存来满足请求,并且堆已经达到了最大大小,则会发生OutOfMemoryError错误)

-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size

-XX:ParallelGCThreads=8
-XX:+CMSClassUnloadingEnabled
-XX:InitiatingHeapOccupancyPercent=70
-XX:+UnlockDiagnosticVMOptions
-XX:+UseConcMarkSweepGC
-Xms512m
-Xmx8192m
-XX:MaxPermSize=256m (in java 8 optional)

例如:在linux平台上为生产模式首选设置。

下载并配置服务器后,以这种方式http://www.ehowstuff.com/how-to-install-and-setup-apache-tomcat-8-on-centos-7-1-rhel-7/

1.在/opt/tomcat/bin/目录下创建setenv.sh文件

   touch /opt/tomcat/bin/setenv.sh

2.打开并写入此参数以设置优选模式。

nano  /opt/tomcat/bin/setenv.sh 

export CATALINA_OPTS="$CATALINA_OPTS -XX:ParallelGCThreads=8"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+CMSClassUnloadingEnabled"
export CATALINA_OPTS="$CATALINA_OPTS -XX:InitiatingHeapOccupancyPercent=70"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UnlockDiagnosticVMOptions"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseConcMarkSweepGC"
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxMetaspaceSize=256M"

3.服务tomcat重启

请注意,JVM使用的内存不仅仅是堆。例如 Java方法、线程栈和本机句柄分配在内存中 与堆分离,以及JVM内部数据结构。

当数据库连接池满时,Java OOM堆空间问题也会出现。

我遇到这个问题是因为我的Hikari连接池(升级到Spring boot 2.4.*时)已满,无法再提供连接(所有活动连接仍在等待从数据库获取结果)。

问题是我们在JPA存储库中的一些本地查询包含ORDER BY ?#{#pageable},这需要很长时间才能获得升级时的结果。

从JPA存储库中的所有本机查询和OOM堆空间问题以及连接池问题中删除ORDER BY ?#{#pageable}。

如果你继续分配和保持对对象的引用,你将填满你所拥有的任何数量的内存。

一个选择是做一个透明的文件关闭和打开时,他们切换选项卡(你只保留一个指向文件的指针,当用户切换选项卡,你关闭和清除所有的对象…它会使文件更改变慢…但是…),并且可能只在内存中保留3或4个文件。

您应该做的另一件事是,当用户打开一个文件时,加载它并拦截任何OutOfMemoryError,然后(因为不可能打开该文件)关闭该文件,清除其对象并警告用户他应该关闭未使用的文件。

您动态扩展虚拟内存的想法并不能解决这个问题,因为机器的资源是有限的,所以您应该小心处理内存问题(或者至少要小心处理它们)。

我所看到的关于内存泄漏的一些提示是:

请记住,如果你把一个东西放入一个集合,然后忘记它,你仍然有一个强引用,所以取消集合,清理它或对它做些什么…如果没有,您将发现内存泄漏很难找到。

也许,使用弱引用的集合(weakhashmap…)可以帮助解决内存问题,但你必须小心使用它,因为你可能会发现你要找的对象已经被收集了。

我发现的另一个想法是开发一个持久的集合,存储在数据库对象最少使用和透明加载。这可能是最好的方法……

如果这个问题发生在Wildfly 8和JDK1.8中,那么我们需要指定MaxMetaSpace设置而不是PermGen设置。

例如,我们需要在wildfly的setenv.sh文件中添加以下配置。 JAVA_OPTS = " $ JAVA_OPTS - xx: MaxMetaspaceSize = 256 "

欲了解更多信息,请查看Wildfly堆问题