解析Linux系统中JVM内存2GB上限的详解
字体：[ ] 类型：转载 时间：
本篇文章是对Linux系统中JVM内存2GB上限进行了详细的分析介绍，需要的朋友参考下
我们通常使用的JVM都是32位的（64位的JVM会损失10-20%的性能，通常不建议使用），而32位程序的寻址空间应该是4GB才对，为什么Linux上的JVM内存只能使用2GB呢？
经过和JDK研发组的人员沟通，终于弄清楚了一些相关的原因。这个问题存在于早期的一些Linux版本中，特别是内核2.5以前的版本，2.6以后的版本就基本上没有这个问题了。原来这些Linux版本对进程有个对内存2GB的限制，是一个地址连续的内存块大小的上限，而JVM的堆空间（heap size）需要连续的地址空间，因此，2GB就是java进程的理论使用的内存上限。
如果java应用需要使用较大的内存，建议使用较新版本的linux，或者修改Linux的应用/内核内存比配置为3GB：1GB。还有就是选择如Solaris等的UNIX操作系统。象Solaris这样的操作系统，在JVM内存管理上没有2GB的限制，因此可以把heap size设置到3.5-3.6GB左右。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具jessesun186 的BLOG
用户名：jessesun186
文章数：26
访问量：6784
注册日期：
阅读量：5863
阅读量：12276
阅读量：418688
阅读量：1106680
51CTO推荐博文
在一些规模稍大的应用中，Java虚拟机（JVM）的内存设置尤为重要，想在项目中取得好的效率，GC（垃圾回收）的设置是第一步。PermGen&space：全称是Permanent&Generation&space.就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域Heap&space：存放Instance。GC(Garbage&Collection)应该不会对PermGen&space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen&space错误Java&Heap分为3个区1.Young2.Old3.PermanentYoung保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可以使用-X参数设定，-Xms&初始Heap大小-Xmx&java&heap最大值&-Xmn&young&generation的heap大小JVM有2个GC线程第一个线程负责回收Heap的Young区第二个线程在Heap不足时，遍历Heap，将Young&区升级为Older区Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC？有如下原因：1.程序内调用了System.gc()或Runtime.gc()。2.一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。3.Java的Heap太小，一般默认的Heap值都很小。4.频繁实例化对象，Release对象&此时尽量保存并重用对象，例如使用StringBuffer()和String()。如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态,许多Server端的Java程序每次GC后最好能有65%的剩余空间经验之谈：1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。注意：1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。Stack的设定每个线程都有他自己的Stack。-Xss&每个线程的Stack大小Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。硬件环境硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。4种GC1、第一种为单线程GC，也是默认的GC，该GC适用于单CPU机器。2、第二种为Throughput&GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。3、第三种为Concurrent&Low&Pause&GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。4、第四种为Incremental&Low&Pause&GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。单文件的JVM内存进行设置默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。java&-Xms64m&-Xmx256m&Test-Xms是设置内存初始化的大小-Xmx是设置最大能够使用内存的大小（最好不要超过物理内存大小）tomcat启动jvm内存设置Linux：在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh添加：JAVA_OPTS='-Xms512m&-Xmx1024m'要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。-Xms：初始值-Xmx：最大值-Xmn：最小值Windows在catalina.bat最前面加入set&JAVA_OPTS=-Xms128m&-Xmx350m&如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,就是说set&JAVA_OPTS=-Xms128m&-Xmx350m&没起作用.上面分配200M内存就OOM了..windows服务执行的是bin/tomcat.exe.他读取注册表中的值,而不是&catalina.bat的设置.解决办法:修改注册表HKEY_LOCAL_MACHINE/SOFTWARE/Apache&Software&Foundation/Tomcat&Service&Manager/Tomcat5/Parameters/JavaOptions原值为-Dcatalina.home=&C:/ApacheGroup/Tomcat&5.0&-Djava.endorsed.dirs=&C:/ApacheGroup/Tomcat&5.0/common/endorsed&-Xrs加入&-Xms300m&-Xmx350m重起tomcat服务,设置生效weblogic启动jvm内存设置在weblogic中，可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。JBoss默认可以使用的内存为64MB&$JBOSSDIR$/bin/run.config&JAVA_OPTS&=&&-server&-Xms128&-Xmx512&Eclipse在所在目录下，键入&eclipse.exe&-vmargs&-Xms256m&-Xmx512m&256m表示JVM堆内存最小值&512m表示JVM堆内存最大Websphere进入控制台去设置：应用程序服务器&&&server1&&&进程定义&&&Java&虚拟机&DIV&style=&FONT-FAMILY:&&COLOR:񱜆&&background-color:&#e8dcc8&&如果采取默认配置的话，JVM默认只能分配到最大64M内存(默认大小和JVM版本有关系)，这在生产环境里肯定是不够，将会导致用户通过WEB方式无法访问应用服务，但是系统进程中，JBOSS服务却没有宕掉的奇怪现象。修改$jboss/bin/run.conf文件，找到“#JAVA_OPTS=”，如果没有该字符串，请添加，并去掉最前面的“#”，修改该字符串(含双引号)为JAVA_OPTS=&-server&-Xms512m&-Xmx512m”，这是分配JVM的最小和最大内存，取决于硬件物理内存的大小，建议均设为物理内存的一半。JAVA_OPTS为：－Xms&520m&-Xmx&1500m&-Xss&128kjboss性能优化:内存紧张的问题JAVA_OPTS：&-Xms&520m&-Xmx&1220m&-Xss&15120k&+XX:AggressiveHeap这个JAVA_OPTS犯了2个致命的错误：1.&+XX:AggressiveHeap会使得&Xms&1220m没有意义。这个参数让jvm忽略Xmx参数，疯狂地吃完一个G物理内存，再吃尽一个G的swap。另外Xmx作为允许jvm使用的最大内存数量，不应该超过物理内存的90％。而之所以使用了这个参数，是因为不加的话，JBoss会在运行一天左右的时间后迅速崩溃，上机课是，甚至出现过半个小时就崩溃的情况。之所以要用这个参数，用swap支持服务器运行，是因为犯了下面的错误：2.&-Xss&15120k这使得JBoss每增加一个线程（thread)就会立即消耗15M内存，而最佳值应该是128K,默认值好像是512k.3.&-Xms指定初始化内存大小所作的修改：1.修改JAVA_OPTS,去掉+XX:AggressiveHeap，修改Xss。现在的JAVA_OPTS为：－Xms&520m&-Xmx&1500m&-Xss&128k2.修改deploy/jbossweb-tomcat55.sar/service.xml将maxThreads根据目前的访问量由默认的250降为75，并使用jboss&4默认未写在标准service.xml里面而jboss&3写入了的2个参数:maxSparseThreads=200，minSparseThreads=1003.修改oracle-ds.xml将最大连接数有150降为50.
了这篇文章
类别：未分类┆阅读(0)┆评论(0)最近在一次压力测试问题分析中，发现运行在tomcat的应用,不管上多少个vuser模拟请求压力，只会耗用200%的cpu，测出应用的tps很低，近10次每秒。经过分析，不是网卡的瓶颈，于是怀疑是内存锁的问题，于是就以下操作与分析。
步骤一：在linux环境上执行jstack -l 线程号 &线程号.log
步骤二：从.log发现如下问题0x8760 的内存变量一个锁住，另一个在获取锁。出现死锁问题。
&http-apr-8090-exec-3898& daemon prio=10 tid=0x0b800 nid=0x192ac waiting for monitor entry [0x08000]
& &java.lang.Thread.State: BLOCKED (on object monitor)
at&org.apache.log4j.Category.callAppenders(Category.java:204)
-&parking to wait for &&0x8760&&(a&org.apache.log4j.Logger)
at&org.apache.log4j.Category.forcedLog(Category.java:391)
at&org.apache.log4j.Category.log(Category.java:856)
at&com.xx.esi.log.logger.(Log4jLogger.java:45)
at&com.xx.esi.log.logger.(FailsafeLogger.java:119)
at&com.xx.cb.web.servlet.HttpService.doPost(HttpService.java:116)
&http-apr-8090-exec-3315& daemon prio=10 tid=0x0f4800 nid=0x19064 runnable [0x0a000]
& &java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOf(Arrays.java:2367)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415)
at java.lang.StringBuffer.append(StringBuffer.java:237)
- locked &0xfe7ee58& (a java.lang.StringBuffer)
at org.apache.log4j.helpers.PatternParser$LiteralPatternConverter.format(PatternParser.java:419)
at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at org.apache.log4j.DailyRollingFileAppender.subAppend(DailyRollingFileAppender.java:369)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked &0xd00418& (a org.apache.log4j.DailyRollingFileAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked &0x8760& (a org.apache.log4j.Logger)
at&com.xx.cb.web.servlet.HttpService.doPost(HttpService.java:116)
步骤三：解决以上代码缺陷。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22919次
排名：千里之外
原创：39篇
(6)(2)(1)(2)(1)(1)(4)(11)(1)(12)