我正在Java 5上编写一个客户端Swing应用程序(图形字体设计器)。最近，我遇到了Java .lang. outofmemoryerror: Java堆空间错误，因为我在内存使用上不保守。用户可以打开无限数量的文件，程序将打开的对象保存在内存中。在快速研究之后，我发现5.0 Java虚拟机和其他人说，在Windows机器上，JVM默认的最大堆大小为64MB。
在这种情况下，我应该如何处理这个约束呢?
我可以使用java的命令行选项增加最大堆大小，但这需要计算出可用的RAM并编写一些启动程序或脚本。此外，增加到某个有限最大值并不能最终摆脱这个问题。
我可以重写一些代码，频繁地将对象持久化到文件系统中(使用数据库也是一样)，以释放内存。它可能会起作用，但可能也要做很多工作。
如果你能告诉我上述想法的细节或一些替代方案，如自动虚拟内存，动态扩展堆大小，那将是伟大的。
当前回答
如果你使用Android Studio，只需用gradle添加这些行。属性文件
org . gradle。jvmargs=- xm2048m -XX: maxpermze =512m -XX:+ heapdumpfdfile -Dfile.encoding=UTF-8
其他回答
大警告----在我的办公室，我们发现(在一些windows机器上)我们不能为Java堆分配超过512m。事实证明，这是由于其中一些机器上安装了卡巴斯基反病毒产品。在卸载该AV产品后，我们发现我们可以分配至少1.6gb，即-Xmx1600m (m是强制性的，否则它将导致另一个错误“太小的初始堆”)工作。
不知道这种情况是否发生在其他反病毒产品上，但据推测，这是因为反病毒程序在每个地址空间中保留了一小块内存，从而防止了单个真正大的分配。
默认情况下，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内部数据结构。
我在其他地方读到过，你可以尝试- catch java.lang.OutOfMemoryError，在catch块上，你可以释放所有你知道可能使用大量内存的资源，关闭连接等等，然后执行System.gc()，然后重新尝试你要做的任何事情。
另一种方式是，虽然，我不知道这是否会工作，但我目前正在测试它是否会在我的应用程序上工作。
这个想法是通过调用System.gc()来进行垃圾收集，这可以增加可用内存。您可以在内存消耗代码执行之后继续检查。
//Mimimum acceptable free memory you think your app needs
long minRunningMemory = (1024*1024);
Runtime runtime = Runtime.getRuntime();
if(runtime.freeMemory()<minRunningMemory)
System.gc();
如果你继续分配和保持对对象的引用，你将填满你所拥有的任何数量的内存。
一个选择是做一个透明的文件关闭和打开时，他们切换选项卡(你只保留一个指向文件的指针，当用户切换选项卡，你关闭和清除所有的对象…它会使文件更改变慢…但是…)，并且可能只在内存中保留3或4个文件。
您应该做的另一件事是，当用户打开一个文件时，加载它并拦截任何OutOfMemoryError，然后(因为不可能打开该文件)关闭该文件，清除其对象并警告用户他应该关闭未使用的文件。
您动态扩展虚拟内存的想法并不能解决这个问题，因为机器的资源是有限的，所以您应该小心处理内存问题(或者至少要小心处理它们)。
我所看到的关于内存泄漏的一些提示是:
请记住，如果你把一个东西放入一个集合，然后忘记它，你仍然有一个强引用，所以取消集合，清理它或对它做些什么…如果没有，您将发现内存泄漏很难找到。
也许，使用弱引用的集合(weakhashmap…)可以帮助解决内存问题，但你必须小心使用它，因为你可能会发现你要找的对象已经被收集了。
我发现的另一个想法是开发一个持久的集合，存储在数据库对象最少使用和透明加载。这可能是最好的方法……
我想添加建议从甲骨文故障排除文章。
线程thread_name异常:Java .lang. outofmemoryerror: Java堆空间
详细消息Java堆空间表示无法在Java堆中分配对象。此错误并不一定意味着内存泄漏
可能的原因:
简单的配置问题，指定的堆大小不足以满足应用程序的要求。 应用程序无意中持有对对象的引用，这可以防止对象被垃圾收集。 过度使用终结符。
此错误的另一个潜在来源来自于过度使用终结器的应用程序。如果类具有finalize方法，则该类型的对象在垃圾收集时不会回收其空间
在垃圾收集之后，对象将排队等待终结，这将在稍后发生。终结器由服务终结队列的守护线程执行。如果终结器线程无法跟上终结队列，那么Java堆就会被填满，并抛出这种类型的OutOfMemoryError异常。
可能导致这种情况的一种场景是，应用程序创建了高优先级线程，导致终结队列的增长速度快于终结线程服务该队列的速度。
