JVM内存限制问题解决方案

22 篇文章 0 订阅

JVM内存限制问题解决方案

2010-09-27 13:14 wzwfly csdn.net 我要评论(0) 字号: T | T
一键收藏,随时查看,分享好友!

这里向大家描述一下JVM内存限制的解决方法,众所周知,JVM内存是受限的,一为机器的体系架构,二为操作系统本身,当然各操作系统的内存管理机制也有区别。

AD:


    你对解决JVM内存限制有什么好的方法吗,这里向大家简单介绍一下,希望对你的学习有所帮助,毕竟各操作系统的内存管理机制也有区别的。

    JVM内存限制解决方案

    众所周知,JVM内存是受限的,一为机器的体系架构,二为操作系统本身。x86,x86-64,SPARC,.....的内存映射是不同,而各操作系统的内存管理机制也有区别。

    1.Heap设定与垃圾回收

    JavaHeap分为3个区,Young,Old和Permanent。Young保存刚实例化的对象。当该区被填满时,GC会将对象移到Old区。Permanent区则负责保存反射对象,本文不讨论该区。

    JVM的Heap分配可以使用-X参数设定

    JVM的Heap分配

    JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时,遍历Heap,将Young区升级为Older区。Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能。

    为什么一些程序频繁发生GC?有如下原因:

    ◆程序内调用了System.gc()或Runtime.gc()。

    ◆一些中间件软件调用自己的GC方法,此时需要设置参数禁止这些GC。

    ◆Java的Heap太小,一般默认的Heap值都很小。

    ◆频繁实例化对象,Release对象。此时尽量保存并重用对象,例如使用StringBuffer()和String()。

    如果你发现每次GC后,Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。

    经验之谈:

    1.Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC,最好让-Xmn值约等于-Xmx的1/3[2]。

    2.一个GUI程序最好是每10到20秒间运行一次GC,每次在半秒之内完成[2]。

    注意:

    1.增加Heap的大小虽然会降低GC的频率,但也增加了每次GC的时间。并且GC运行时,所有的用户线程将暂停,也就是GC期间,Java应用程序不做任何工作。

    2.Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值,因为Java为其他任务分配内存,例如每个线程的Stack等。

    2.Stack的设定

    每个线程都有他自己的Stack。

    Stack的大小限制着线程的数量,也就是说会出现JVM内存限制。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小,例如-Xss1024K。如果Stack太小,也会导致Stack溢漏。

    3.硬件环境

    硬件环境也影响GC的效率,例如机器的种类,内存,swap空间,和CPU的数量。如果你的程序需要频繁创建很多transient对象,会导致JVM频繁GC。这种情况你可以增加机器的内存,来减少Swap空间的使用[2]。

    4.4种GC

    这里来看一下四种垃圾回收机制,通过JVM垃圾回收可以一定程度上解决JVM内存限制问题。

    第一种为单线程GC,也是默认的GC。,该GC适用于单CPU机器。

    第二种为ThroughputGC,是多线程的GC,适用于多CPU,使用大量线程的程序。第二种GC与第一种GC相似,不同在于GC在收集Young区是多线程的,但在Old区和第一种一样,仍然采用单线程。-XX:+UseParallelGC参数启动该GC。

    第三种为ConcurrentLowPauseGC,类似于第一种,适用于多CPU,并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时,运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。

    第四种为IncrementalLowPauseGC,适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时,回收一部分Old区对象。-Xincgc参数启动该GC。

    • 0
      点赞
    • 0
      收藏
      觉得还不错? 一键收藏
    • 0
      评论
    Tomcat内存溢出的三种情况及解决办法分析 Tomcat内存溢出的原因 在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存原因是不一样的,当然处理方式也不一样。 这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况: 1.OutOfMemoryError: Java heap space 2.OutOfMemoryError: PermGen space 3.OutOfMemoryError: unable to create new native thread. Tomcat内存溢出解决方案 对于前两种情况,在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。(-Xms -Xmx -XX:PermSize -XX:MaxPermSize) 最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。 第一种:是堆溢出。 在JVM中如果98%的时间是用于GC且可用的 Heap size 不足2%的时候将抛出此异常信息。 没有内存泄露的情况下,调整-Xms -Xmx参数可以解决。 -Xms:初始堆大小 -Xmx:最大堆大小 但堆的大小受下面三方面影响: 1.相关操作系统的数据模型(32-bt还是64-bit)限制;(32位系统下,一般限制在1.5G~2G;我在2003 server 系统下(物理内存:4G和6G,jdk:1.6)测试 1612M,64为操作系统对内存限制。) 2.系统的可用虚拟内存限制; 3.系统的可用物理内存限制。 堆的大小可以使用 java -Xmx***M version 命令来测试。支持的话会出现jdk的版本号,不支持会报错。 -Xms -Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -Xmx1024m 第二种:永久保存区域溢出 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域,它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的问题。http://www.javaeye.com/topic/80620?page=1 的帖子有讨论的这个问题。可能是由于这些框架会动态class,而且jvm的gc是不会清理PemGen space的,导致内存溢出。 这一个一般是加大-XX:PermSize -XX:MaxPermSize 来解决问题。 -XX:PermSize 永久保存区域初始大小 -XX:PermSize 永久保存区域初始最大值 这一般结合第一条使用,比如 set JAVA_OPTS= -Xms1024m -Xmx1024m -XX:PermSize=128M -XX:PermSize=256M 有一点需要注意:java -Xmx***M version 命令来测试的最大堆内存是 -Xmx与 -XX:PermSize的 和 比如系统支持最大的jvm堆大小事1.5G,那 -Xmx1024m -XX:PermSize=768M 是无法运行的。 第三种:无法创建新的线程。 这种现象比较少见,也比较奇怪,主要是和jvm与系统内存的比例有关。 这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G),并且它至少要占用可用内存的一半。有人发现,在线程个数很多的情况下,你分配给JVM内存越多,那么,上述错误发生的可能性就越大。 产生这种现象的原因如下(从这个blog中了解到原因:http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html): 每一个32位的进程最多可以使用2G的可用内存,因为另外2G被操作系统保留。这里假设使用1.5G给JVM,那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载,那么真正剩下的也许只有400M,现在关键的地方出现了:当你使用Java创建一个线程,在JVM内存里也会创建一个Thread对象,但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范),操作系统会在余下的400兆内存里创建这个物理线程,而不是在JVM的1500M的内存堆里创建。在jdk1.4里头,默认的栈大小是256KB,但是在jdk1.5里头,默认的栈大小为1M每线程,因此,在余下400M的可用内存里边我们最多也只能创建400个可用线程。 这样结论就出来了,要想创建更多的线程,你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。 给出一个有关能够创建线程的最大个数的估算公式: (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads 对于jdk1.5而言,假设操作系统保留120M内存: 1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads 1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads 在2000/XP/2003的boot.ini里头有一个启动选项,好像是:/PAE /3G ,可以让用户进程最大内存扩充至3G,这时操作系统只能占用最多1G的虚存。那样应该可以让JVM创建更多的线程。 因此这种情况需要结合操作系统进行相关调整。 因此:我们需要结合不同情况对tomcat内存分配进行不同的诊断才能从根本上解决问题。 以上就是针对Tomcat内存溢出的几种解决方案。本文来自George的博客:《tomcat内存溢出总结》
    当你在运行Java应用程序的JAR包时遇到JVM闪退问题,你可以尝试以下几种方法来解决: 1. 增加内存:尝试增加JVM内存限制,特别是堆内存大小。通过使用-Xmx参数增加最大堆内存限制,例如:java -Xmx4g -jar yourApp.jar。这可能有助于解决由于内存不足导致的闪退问题。 2. 检查依赖项:确保你的JAR包和相关的依赖项是正确的版本,并且相互兼容。不正确的依赖项可能导致闪退问题。确保你正确地管理和导入依赖项,可以使用构建工具(如Maven或Gradle)来自动管理依赖关系。 3. 检查日志:查看JVM生成的错误日志,通常位于应用程序的工作目录中。错误日志可能会提供有关导致闪退的异常信息和堆栈跟踪。通过分析日志,你可以获得对问题的更深入理解。 4. 升级JVM:如果你使用较旧版本的JVM,请尝试升级到最新版本。新版本的JVM通常会修复一些已知的问题和漏洞,并提供更好的稳定性和性能。 5. 检查代码逻辑:检查你的代码逻辑,确保没有潜在的问题,如无限循环、资源未正确释放等。通过使用调试工具或日志语句来追踪代码执行路径,有助于找到可能导致闪退的问题。 6. 调整JVM参数:根据应用程序的需求,适当地调整JVM参数,如垃圾回收器类型、线程栈大小等。不同的应用程序可能需要不同的JVM参数配置,通过调整这些参数可能有助于解决闪退问题。 7. 与开发社区寻求帮助:如果上述方法都无法解决问题,你可以向Java开发社区或论坛提问,寻求其他开发者的帮助。他们可能会提供更具体的建议和解决方案。 请注意,JVM闪退问题可能由于多种原因引起,上述方法仅提供了一些常见的解决途径。对于特定的问题,可能需要更详细的调查和分析才能找到准确的解决方案

    “相关推荐”对你有帮助么?

    • 非常没帮助
    • 没帮助
    • 一般
    • 有帮助
    • 非常有帮助
    提交
    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值