JAVA HEAP SPACE解决方法和JVM参数设置
- JAVA HEAP SPACE解决方法和JVM参数设置
-
- 原因分析
- 设置
- 异常分析
- Java堆的管理—垃圾回收提到一下几点,很不错,或许可以作为写程序时候的准则:
- jvm 内存查看与分析工具
JAVA HEAP SPACE解决方法和JVM参数设置
在JVM中如果98%的时间是用于GC(Garbage Collection)且可用的 Heap size 不足2%的时候将抛出异常信息,java.lang.OutOfMemoryError: Java heap space。
所以产生这个异样的原因通常有两种:
1.程序中出现了死循环
2.程序占用内存太多,超过了JVM堆设置的最大值。
原因分析
第二种情况,我们手工扩大JVM堆的参数设置。JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置。在JVM启动时,JVM堆会自动设置heap size值。通常情况下,初始空间(即-Xms)默认值是物理内存的1/64,最大空间是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。这里对各个参数的意义解释一下:
-Xms:初始值
-Xmx:最大值
-Xmn:最小值
Heap
Size的设置不宜太小,也不宜太大。若设置太小程序的响应速度会变慢了,因为GC占用了更多的时间,而应用分配到的执行时间较少。太大也会造成空间的浪费,而且也会影响其他程序的正常运行。Heap
Size 最大最好不要超过可用物理内存的80%。建议将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。
设置的方法主要有以下几个:
-
就是在执行JAVA类文件时加上这个参数,其中className是需要执行的确类名。(包括包名)如:java -Xms32m -Xmx800m className 这个不仅解决问题了,而且执行的速度比没有设置的时候快很多。
-
可以在windows更改系统环境变量加上JAVA_OPTS=-Xms64m -Xmx512m。
-
如果用的tomcat,在windows下,可以在C: omcat5.5.9incatalina.bat(具体路径根据自己tomcat的位置而定) 中加上:set JAVA_OPTS=-Xms64m -Xmx256m (大小依自己内存而定)位置在: rem Guess CATALINA_HOME if not defined 这行的下面加合适.
-
如果是linux系统Linux 在{tomcat_home}/bin/catalina.sh的前面,加 set JAVA_OPTS=’-Xms64 -Xmx512’
设置
1、设置环境变量
set JAVA_OPTS= -Xms32m -Xmx512m
可以根据自己机器的内存进行更改,但本人测试这种方法并没有解决问题。可能是还有哪里需要设置。
2、 java -Xms32m -Xmx800m className
就是在执行JAVA类文件时加上这个参数,其中className是需要执行的确类名。(包括包名)
这个解决问题了。而且执行的速度比没有设置的时候快很多。
异常分析
使用Java程序从数据库中查询大量的数据时出现异常:
java.lang.OutOfMemoryError: Java heap space
在JVM中如果98%的时间是用于GC且可用的 Heap size 不足2%的时候将抛出此异常信息。
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.
JVM在启动的时候会自动设置Heap
size的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms
-Xmx等选项可进行设置。 例如:java -jar -Xmn16m -Xms64m -Xmx128m MyApp.jar
如果Heap Size设置偏小,除了这些异常信息外,还会发现程序的响应速度变慢了。GC占用了更多的时间,而应用分配到的执行时间较少。
Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。
Heap size的 -Xms -Xmn 设置不要超出物理内存的大小。否则会提示“Error occurred during initialization of VM Could not reserve enough space for object
heap”。
Java堆的管理—垃圾回收提到一下几点,很不错,或许可以作为写程序时候的准则:
(1)不要试图去假定垃圾收集发生的时间,这一切都是未知的。比如,方法中的一个临时对象在方法调用完毕后就变成了无用对象,这个时候它的内存 就可以被释放。
(2)Java中提供了一些和垃圾收集打交道的类,而且提供了一种强行执行垃圾收集的方法–调用System.gc(),但这同样是个不确定 的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集,它只不过会向JVM发出这样一个申请,到底是否真正执行垃圾收集,一切都是个未知数。
(3)挑选适合自己的垃圾收集器。一般来说,如果系统没有特殊和苛刻的性能要求,可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收 集器,比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置,有比较多的闲置资源,可以考虑使用并行标记/清除收集器。
(4)关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的,不要让自己的一个小错误导致内存出现大漏洞。
(5)尽早释放无用对象的引用。
jvm 内存查看与分析工具
1:gc日志输出
在jvm启动参数中加入
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimestamps
-XX:+PrintGCApplicationStopedTime
jvm将会按照这些参数顺序输出gc概要信息,详细信息,gc时间信息,gc造成 的应用暂停时间。如果在刚才的参数后面加入参数 -Xloggc:文件路径,gc信息将会输出到指定的文件中。其他参数还有
-verbose:gc和-XX:+PrintTenuringDistribution等。
2:jconsole
jconsole是jdk自带的一个内存分析工具,它提供了图形界面。可以查看到被监控的jvm的内存信息,线程信息,类加载信息,MBean信息。
jconsole位于jdk目录下的bin目录,在windows下是
jconsole.exe
,在unix和linux下是
jconsole.sh,jconsole可以监控本地应用,也可以监控远程应用。文章来源:https://www.toymoban.com/news/detail-463424.html
要监控本地应用,执行jconsole pid,pid就是运行的java进程id,如果不带上pid参数,则执行jconsole命令后,会看到一个对话框弹出,上面列出了本地的java进 程,可以选择一个进行监控。如果要远程监控,则要在远程服务器的jvm参数里加入一些东西,因为jconsole的远程监控基于jmx的,关于 jconsole详细用法,请见专门介绍jconsle的文章,我也会在博客里专门详细介绍jconsole。文章来源地址https://www.toymoban.com/news/detail-463424.html
到了这里,关于JAVA HEAP SPACE解决方法和JVM参数设置的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!