堆内存设置
JVM堆内存分为2块：Permanent Space 和 Heap Space。
Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。
Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。
所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个Eden区，2个Survivor区（from 和 to）。
大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当一个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当另一个Survivor区也满了的时候，从前一个Survivor区复制过来的并且此时还存活的对象，将可能被复制到年老代。
2个Survivor区是对称的，没有先后关系，所以同一个Survivor区中可能同时存在从Eden区复制过来对象，和从另一个Survivor区复制过来的对象；而复制到年老区的只有从另一个Survivor区过来的对象。而且，因为需要交换的原因，Survivor区至少有一个是空的。特殊的情况下，根据程序需要，Survivor区是可以配置为多个的（多于2个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
针对年轻代的垃圾回收即 Young GC。
在年轻代中经历了N次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
针对年老代的垃圾回收即 Full GC。
用于存放静态类型数据，如 Java Class, Method 等。持久代对垃圾回收没有显著影响。但是有些应用可能动态生成或调用一些Class，例如 Hibernate CGLib 等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。
所以，当一组对象生成时，内存申请过程如下：
JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
当Eden区空间足够时，内存申请结束。否则执行下一步。
JVM试图释放在Eden区中所有不活跃的对象（Young GC）。释放后若Eden空间仍然不足以放入新对象，JVM则试图将部分Eden区中活跃对象放入Survivor区。
Survivor区被用来作为Eden区及年老代的中间交换区域。当年老代空间足够时，Survivor区中存活了一定次数的对象会被移到年老代。
当年老代空间不够时，JVM会在年老代进行完全的垃圾回收（Full GC）。
Full GC后，若Survivor区及年老代仍然无法存放从Eden区复制过来的对象，则会导致JVM无法在Eden区为新生成的对象申请内存，即出现“Out of Memory”。
OOM（“Out of Memory”）异常一般主要有如下2种原因：
1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace
这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。
例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。
2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace
通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize 调大（一般256m能满足绝大多数应用程序需求）。将部分Java类放到容器共享区（例如Tomcat share lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。
-Xmx3550m：设置JVM最大堆内存为3550M。
-Xms3550m：设置JVM初始堆内存为3550M。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xss128k：设置每个线程的栈大小。JDK5.0以后每个线程栈大小为1M，之前每个线程栈大小为256K。应当根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在左右。需要注意的是：当这个值被设置的较大（例如&2MB）时将会在很大程度上降低系统的性能。
-Xmn2g：设置年轻代大小为2G。在整个堆内存大小确定的情况下，增大年轻代将会减小年老代，反之亦然。此值关系到JVM垃圾回收，对系统性能影响较大，官方推荐配置为整个堆大小的3/8。
-XX:NewSize=1024m：设置年轻代初始值为1024M。
-XX:MaxNewSize=1024m：设置年轻代最大值为1024M。
-XX:PermSize=256m：设置持久代初始值为256M。
-XX:MaxPermSize=256m：设置持久代最大值为256M。
-XX:NewRatio=4：设置年轻代（包括1个Eden和2个Survivor区）与年老代的比值。表示年轻代比年老代为1:4。
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的比值。表示2个Survivor区（JVM堆内存年轻代中默认有2个大小相等的Survivor区）与1个Eden区的比值为2:4，即1个Survivor区占整个年轻代大小的1/6。
-XX:MaxTenuringThreshold=7：表示一个对象如果在Survivor区（救助空间）移动了7次还没有被垃圾回收就进入年老代。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代，对于需要大量常驻内存的应用，这样做可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代存活时间，增加对象在年轻代被垃圾回收的概率，减少Full GC的频率，这样做可以在某种程度上提高服务稳定性。
-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么？
高优先级：-XX:NewSize/-XX:MaxNewSize
中优先级：-Xmn（默认等效
-Xmn=-XX:NewSize=-XX:MaxNewSize=?）
低优先级：-XX:NewRatio
推荐使用-Xmn参数，原因是这个参数简洁，相当于一次设定 NewSize/MaxNewSIze，而且两者相等，适用于生产环境。-Xmn 配合 -Xms/-Xmx，即可将堆内存布局完成。
-Xmn参数是在JDK 1.4 开始支持。
垃圾回收器选择
JVM给出了3种选择：串行收集器、并行收集器、并发收集器。串行收集器只适用于小数据量的情况，所以生产环境的选择主要是并行收集器和并发收集器。
默认情况下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行智能判断。
串行收集器
-XX:+UseSerialGC：设置串行收集器。
并行收集器（吞吐量优先）
-XX:+UseParallelGC：设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时有多少个线程一起进行垃圾回收。此值建议配置与CPU数目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0开始支持对年老代并行收集。
-XX:MaxGCPauseMillis=100：设置每次年轻代垃圾回收的最长时间（单位毫秒）。如果无法满足此时间，JVM会自动调整年轻代大小，以满足此时间。
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动调整年轻代Eden区大小和Survivor区大小的比例，以达成目标系统规定的最低响应时间或者收集频率等指标。此参数建议在使用并行收集器时，一直打开。
并发收集器（响应时间优先）
-XX:+UseConcMarkSweepGC：即CMS收集，设置年老代为并发收集。CMS收集是JDK1.4后期版本开始引入的新GC算法。它的主要适合场景是对响应时间的重要性需求大于对吞吐量的需求，能够承受垃圾回收线程和应用线程共享CPU资源，并且应用中存在比较多的长生命周期对象。CMS收集的目标是尽量减少应用的暂停时间，减少Full GC发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存。
-XX:+UseParNewGC：设置年轻代为并发收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此参数。
-XX:CMSFullGCsBeforeCompaction=0：由于并发收集器不对内存空间进行压缩和整理，所以运行一段时间并行收集以后会产生内存碎片，内存使用效率降低。此参数设置运行0次Full GC后对内存空间进行压缩和整理，即每次Full GC后立刻开始压缩和整理内存。
-XX:+UseCMSCompactAtFullCollection：打开内存空间的压缩和整理，在Full GC后执行。可能会影响性能，但可以消除内存碎片。
-XX:+CMSIncrementalMode：设置为增量收集模式。一般适用于单CPU情况。
-XX:CMSInitiatingOccupancyFraction=70：表示年老代内存空间使用到70%时就开始执行CMS收集，以确保年老代有足够的空间接纳来自年轻代的对象，避免Full GC的发生。
其它垃圾回收参数
-XX:+ScavengeBeforeFullGC：年轻代GC优于Full GC执行。
-XX:-DisableExplicitGC：不响应 System.gc() 代码。
-XX:+UseThreadPriorities：启用本地线程优先级API。即使 java.lang.Thread.setPriority() 生效，不启用则无效。
-XX:SoftRefLRUPolicyMSPerMB=0：软引用对象在最后一次被访问后能存活0毫秒（JVM默认为1000毫秒）。
-XX:TargetSurvivorRatio=90：允许90%的Survivor区被占用（JVM默认为50%）。提高对于Survivor区的使用率。
辅助信息参数设置
-XX:-CITime：打印消耗在JIT编译的时间。
-XX:ErrorFile=./hs_err_pid.log：保存错误日志或数据到指定文件中。
-XX:HeapDumpPath=./java_pid.hprof：指定Dump堆内存时的路径。
-XX:-HeapDumpOnOutOfMemoryError：当首次遭遇内存溢出时Dump出此时的堆内存。
-XX:OnError=”;”：出现致命ERROR后运行自定义命令。
-XX:OnOutOfMemoryError=”;”：当首次遭遇内存溢出时执行自定义命令。
-XX:-PrintClassHistogram：按下 Ctrl+Break 后打印堆内存中类实例的柱状信息，同JDK的 jmap -histo 命令。
-XX:-PrintConcurrentLocks：按下 Ctrl+Break 后打印线程栈中并发锁的相关信息，同JDK的 jstack -l 命令。
-XX:-PrintCompilation：当一个方法被编译时打印相关信息。
-XX:-PrintGC：每次GC时打印相关信息。
-XX:-PrintGCDetails：每次GC时打印详细信息。
-XX:-PrintGCTimeStamps：打印每次GC的时间戳。
-XX:-TraceClassLoading：跟踪类的加载信息。
-XX:-TraceClassLoadingPreorder：跟踪被引用到的所有类的加载信息。
-XX:-TraceClassResolution：跟踪常量池。
-XX:-TraceClassUnloading：跟踪类的卸载信息。
关于参数名称等
标准参数（-），所有JVM都必须支持这些参数的功能，而且向后兼容；例如：
-client——设置JVM使用Client模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或开发调试；在32位环境下直接运行Java程序默认启用该模式。
-server——设置JVM使Server模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有64位能力的JDK环境下默认启用该模式。
非标准参数（-X），默认JVM实现这些参数的功能，但是并不保证所有JVM实现都满足，且不保证向后兼容；
非稳定参数（-XX），此类参数各个JVM实现会有所不同，将来可能会不被支持，需要慎重使用；
JVM服务参数调优实战
大型网站服务器案例
承受海量访问的动态Web应用
服务器配置：8 CPU, 8G MEM, JDK 1.6.X
参数方案：
-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC
调优说明：
-Xmx 与 -Xms 相同以避免JVM反复重新申请内存。-Xmx 的大小约等于系统内存大小的一半，即充分利用系统资源，又给予系统安全运行的空间。
-Xmn1256m 设置年轻代大小为1256MB。此值对系统性能影响较大，Sun官方推荐配置年轻代大小为整个堆的3/8。
-Xss128k 设置较小的线程栈以支持创建更多的线程，支持海量访问，并提升系统性能。
-XX:SurvivorRatio=6 设置年轻代中Eden区与Survivor区的比值。系统默认是8，根据经验设置为6，则2个Survivor区与1个Eden区的比值为2:6，一个Survivor区占整个年轻代的1/8。
-XX:ParallelGCThreads=8 配置并行收集器的线程数，即同时8个线程一起进行垃圾回收。此值一般配置为与CPU数目相等。
-XX:MaxTenuringThreshold=0 设置垃圾最大年龄（在年轻代的存活次数）。如果设置为0的话，则年轻代对象不经过Survivor区直接进入年老代。对于年老代比较多的应用，可以提高效率；如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。根据被海量访问的动态Web应用之特点，其内存要么被缓存起来以减少直接访问DB，要么被快速回收以支持高并发海量请求，因此其内存对象在年轻代存活多次意义不大，可以直接进入年老代，根据实际应用效果，在这里设置此值为0。
-XX:+UseConcMarkSweepGC 设置年老代为并发收集。CMS（ConcMarkSweepGC）收集的目标是尽量减少应用的暂停时间，减少Full GC发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存，适用于应用中存在比较多的长生命周期对象的情况。
内部集成构建服务器案例
高性能数据处理的工具应用
服务器配置：1 CPU, 4G MEM, JDK 1.6.X
参数方案：
-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m
调优说明：
-XX:PermSize=196m -XX:MaxPermSize=196m 根据集成构建的特点，大规模的系统编译可能需要加载大量的Java类到内存中，所以预先分配好大量的持久代内存是高效和必要的。
-Xmn320m 遵循年轻代大小为整个堆的3/8原则。
-Xms768m -Xmx1024m 根据系统大致能够承受的堆内存大小设置即可。
在64位服务器上运行应用程序，构建执行时，用 jmap -heap 11540 命令观察JVM堆内存状况如下：
Attaching to process ID 11540, please wait…
Debugger attached successfully.
Server compiler detected.
JVM version is 20.12-b01
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize
(1024.0MB)
MaxNewSize
= .1875MB)
SurvivorRatio
MaxPermSize
Heap Usage:
PS Young Generation
Eden Space:
capacity =
39.81% used
From Space:
capacity = .5625MB)
= .0625MB)
99.03% used
capacity = .0MB)
= 0 (0.0MB)
PS Old Generation
capacity =
9.184% used
PS Perm Generation
capacity =
(114.16MB)
41.285% used
结果是比较健康的。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1569次
排名：千里之外
原创：18篇
转载：22篇
(7)(12)(7)(7)(1)(6)Posts - 24,
Articles - 3,
Comments - 8
14:40 by chloe_zhou, ... 阅读,
　　有时我们需要编写一些比较耗内存的java程序，如压缩解压缩、数据库备份等，运行这些代码时容易报&java.lang.OutOfMemoryError: Java heap space& 异常，这时就需要增大JVM的堆大小了。不管是运行在Tomcat下的网站型程序还是纯java桌面程序，都有很多种设置方法，但是我今天发现不是每个方法都是那么有效，或者说有的方法有特殊值得注意的地方，只有小心谨慎正确地设置才能真正实现增大堆大小。下面我的测试与分析是基于MyEclipse1.6.0和Tomcat6.0.1环境下的，电脑内存为2G。
　　先考虑java桌面程序，因为即使是Tomcat下的Web程序也建立在jvm和纯java代码上的，且单元测试一般不需要在Tomcat下运行。在单独运行某个java文件中的源码时，有以下几种方法设置jvm堆的大小。
　　1. 依次选择菜单：Run--&Open Debug Dialog...，打开Debug对话框，在右边区域选择"(x)=Arguments"选项卡，在选项卡中的"VM arguments"下的文本框中填入 -Xms512m -Xmx512m ，即将JVM的最小分配内存和最大分配内存均设置成实际内存的1/4，注意两项设置之间需要有一个或多个空格。这个方法很有效，我测试过，一旦设置完这一项(不用重启MyEclipse)，运行之前报错的程序后马上显示正常结果(如果程序本身木有问题的话)~其设置截图如下，
　　这个方法只是对当前需要运行的java类有效，如果选择左侧列表中的其他可运行的java类，则 "VM arguments"中的内容为空，因此此方法适用于单元测试。
　　2. 依次选择菜单：Window --& Preferences，打开"Preferences"对话框，在左侧树形列表中依次进入Java --& Installed JREs，在右侧列出的的jdk中选中自己默认使用的jdk，如我自己用的"jdk1.6.0"。然后点击"Edit"按钮，打开"Edit JRE"对话框，将对话框中"Default VM Arguments"项设置为 -Xmx512m ，这种设置应该对项目中其他所有类都有效。设置界面如下,
　　注意，MyEclipse一般有自带的jdk，名字为"MyEclipse"，最好在之前打开的"Preferences"对话框中将其Remove掉，因为在MyEclipse中运行的可执行java类时，默认是通过 MyEclipse自带的jdk运行，这样就导致设置无效。当然，将其自带的jdk的"Default VM Arguments"也一并设置的话也是可以的，设置后不用重启MyEclipse，直接运行java程序就可以了。
对于在tomcat中运行的web程序，可以通过设置tomcat的相关参数来调大JVM的堆分配大小，方法有下述几种。
　　1. 修改catalina.bat文件。catalina.bat文件位于Tomcat安装目录下的bin文件夹下，可以用记事本或者EditPlus打开，用Ctrl+F快捷键寻找"rem Guess CATALINA_HOME if not defined"，在其下方添加一行"set JAVA_OPTS=-Xms512m &Xmx512m" 即可。
　　2. 依次进入Window --& Preferences --&MyEclipse --& Servers --& Tomcat --& Tomcat 6.x --& JDK，设置"Optical Java VM arguments"为 "-Xms512m -Xmx512m"。jvm堆大小设置相关_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
jvm堆大小设置相关
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩2页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢iceeggplant 的BLOG
用户名：iceeggplant
文章数：79
评论数：19
访问量：95712
注册日期：
阅读量：5863
阅读量：12276
阅读量：322129
阅读量：1032645
51CTO推荐博文
摘自网上参考加总结的，比较乱，一直没有时间整理，现在是忙中茫，先贴着后期整理吧：样例：JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true \-server -Xmx2600m -Xms2600m -Xmn2000m \-XX:SurvivorRatio=8 \-XX:PermSize=256m \-XX:MaxPermSize=256m \-Xss128k \-XX:MaxTenuringThreshold=7 \-XX:ParallelGCThreads=8 \-XX:GCTimeRatio=19 \-Xnoclassgc \-XX:+DisableExplicitGC \-XX:+UseParNewGC \-XX:+UseConcMarkSweepGC \-XX:+CMSPermGenSweepingEnabled \-XX:+UseCMSCompactAtFullCollection \-XX:CMSFullGCsBeforeCompaction=0 \-XX:CMSInitiatingOccupancyFraction=70 \XX:+PrintClassHistogram \-XX:+PrintGCDetails \-XX:+PrintGCTimeStamps \-XX:+PrintGCApplicationConcurrentTime \-XX:+PrintGCApplicationStoppedTime \-XX:+PrintTenuringDistribution \-Xloggc:/home/saas/apache-tomcat-6.0.36/log/tomcat_gc.log \-Doracle.jdbc.V8Compatible=true"tomcat内存溢出总结在生产环境中tomcat内存配置不好很容易出现内存溢出。造成内存原由是不一样的，当然处理方式也不一样。　　这里根据平时遇到的情况和有关资料执行 一个总结。多见的一般会有下面三种情况：　　1.OutOfMemoryError: Java heap space　　2.OutOfMemoryError: PermGen space　　3.OutOfMemoryError: unable to create new native thread.　　对于前两种情况，在运用 本身没有内存泄露的情况下可以用配置 tomcat jvm参数来处理。（-Xms -Xmx -XX:PermSize　 -XX:Maxp ermSize）　　最后一种可能须要调整操作系统和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项目中也很容易出现这样的疑问。/topic/80620?page=1　的帖子有讨论的这个疑问。可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen space的，导致内存溢出。-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中了解到原由：/hexiong/blog/item/16dc9e518fb10cc.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代码里边。　　给出一个有关能够建立线程的最大个数的估算公式：　　(Maxp rocessMemory - 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内存分配执行 不同的诊断才能从根本上处理疑问一些优化参数说明：LargePageSizeInBytes &指定 Java heap 的分页页面大小， 内存页的大小， 不可设置过大， 会影响Perm的大小DisableExplicitGC 禁止 java 程序中的 full gc，如 System.gc() 的调用. 最好加上么，防止程序在代码里误用了。对性能造成冲击UseParNewGC &指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优点，可以和 CMS gc 一起使用。 CMSParallelRemarkEnabled &在使用 UseParNewGC 的情况下，尽量减少 mark 的时间UseConcMarkSweepGC &指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server。 UseCMSCompactAtFullCollection 在使用 concurrent gc 的情况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减少。 UseFastAccessorMethods &get,set 方法转成本地代码。UseCMSInitiatingOccupancyOnly &指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集-XX:+UseCMSInitiatingOccupancyOnly & 仅仅使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC-XX:CMSInitiatingOccupancyFraction=70 &CMS堆上， 使用70％后开始CMS收集相比之下，还是并发回收比较好，性能比较高，只要能解决ParNewGC（并行回收年轻代）时的promotion failed错误就一切好办了，查了很多文章，发现引起promotion failed错误的原因是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，所以执行Full GC。CMSInitiatingOccupancyFraction=70表示年老代占到约70%时就开始执行CMS，这样就不会出现Full GC了。。CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100&=Xmn就不会出现promotion failed。假如应用中Xmx是6000，Xmn是512，那么Xmx-Xmn是5488兆，也就是年老代有5488 兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是8兆，所以即使Xmn（也就是年轻代共512兆）里所有对象都搬到年老代里，548兆的空间也足够了，所以只要满 足上面的公式，就不会出现垃圾回收时的promotion failed；因此这个参数的设置必须与Xmn关联在一起。二.调整 jvm参数A：JVM启动参数共分为三类： & & & &其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容； & & & &其二是非标准参数（-X），指的是JVM底层的一些配置参数，这些参数在一般开发中默认即可，不需要任何配置。但是在生产环境中，并不保证所有jvm实现都满足，所以为了提高性能，往往需要调整这些参数，以求系统达到最佳性能。另外这些参数不保证向后兼容，也即是说“如有变更，恕不在后续版本的JDK通知”（这是官网上的原话）； & & & &其三是非Stable参数（-XX），这类参数在jvm中是不稳定的，不适合日常使用的，后续也是可能会在没有通知的情况下就直接取消了，需要慎重使用。B：而JVM 内存又可分为三个主要的域 ： & & & &新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便进入旧域。而在永久域中是用来存储JVM自己的反射对象的，如class和method对象，而且GC(GarbageCollection)不会在主程序运行期对永久域进行清理。其中新域和旧域属于堆，永久域是一个独立域并且不认为是堆的一部分。C：各主要参数的作用如下 ：====================1.堆设置
& & & &-Xms：设置jvm内存的初始大小 & & & &-Xmx：设置jvm内存的最大值 & & & &-Xmn：设置新域的大小（这个似乎只对 jdk1.4来说是有效的，后来就废弃了）；年轻代大小整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8 & & & &-Xss：设置每个线程的堆栈大小(也就是说,在相同物理内存下，减小这个值能生成更多的线程) & & & &-XX：NewRatio :设置新域与旧域之比，如-XX：NewRatio = 4就表示新域与旧域之比为1：4设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
& & & &-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6 & & & &-XX:NewSize：设置新域的初始值 & & & &-XX:MaxNewSize ：设置新域的最大值 & & & &-XX:PermSize：设置永久域的初始值 & & & &-XX:MaxPermSize：设置永久域的最大值 & & & &-XX:SurvivorRatio=n:设置新域中Eden区与两个Survivor区的比值。（Eden区主要是用来存放新生的对象，而两个 Survivor区则用来存放每次垃圾回收后存活下来的对象） & & & &-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。D：常见的错误 ： & & & &java.lang.OutOfMemoryError相信很多开发人员都用到过，这个主要就是JVM参数没有配好引起的，但是这种错误又分两种：java.lang.OutOfMemoryError:Java heap space和java.lang.OutOfMemoryError: PermGenspace(Permanent Generation space永久保存区域)，其中前者是有关堆内存的内存溢出，可以同过配置-Xms和-Xmx参数来设置，而后者是有关永久域的内存溢出，可以通过配置 -XX:MaxPermSize来设置。下面是个例子,请根据实际情况进行修改,修改run.conf文件中的如下内容： JAVA_OPTS="-Xms256m-Xmx2048m -XX:NewSize=256m -XX:MaxNewSize=512m -XX:PermSize=128m-XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled-XX:+CMSClassUnloadingEnabled -Djboss.platform.mbeanserver"说说为什么会内存益出： &PermGen space这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。 解决方法： 手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行： JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。二、java.lang.OutOfMemoryError: Java heap space Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值===========================================================================================优化进价篇：===========================================================================================2.收集器设置 吞吐量优先的并行收集器：并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等典型配置： -XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。 -XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。 -XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。响应时间优先的并发收集器：并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。 典型配置： -XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。 -XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。 -XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片3.垃圾回收统计信息 ■-XX:+PrintGC■-XX:+PrintGCDetails■-XX:+PrintGCTimeStamps■-Xloggc:filename=============================================================================参考大型电商的jvm参数配置，通过研究网上大牛们的优化经验建议，对于我们自己的环境: 例8G内存，4核的jvm优化建议及参数说明： &1. 一般把Xms与Xmx两个值设成一样是最优的做法，Xmx最好不要超过可用物理内存的80%。 建议值：-Xmx6000m -Xms6000m
&对于年轻代Xmn的大小：整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。但是也有建议为Xmx的1/4。（此值待定） &2. -XX:LargePageSizeInBytes：指定 Java heap 的分页页面大小
& & & & &建议：内存页的大小，不可设置过大，会影响Perm的大小，JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置，JVM在启动的时候会自动设置Heap size的值，其初始空间通常为是物理内存的1/64。 建议值为128m. &4. &-XX:+DisableExplicitGC : 禁止 java 程序中的 full gc，如 System.gc() 的调用. & & & & &建议：禁用掉，防止程序在代码里误用了。对性能造成冲击。进阶优化： &5. -XX：UseParNewGC：指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优点，可以和 CMS gc 一起使用。 & & -XX：CMSParallelRemarkEnabled &在使用 UseParNewGC 的情况下，尽量减少 mark 的时间 &
&6. -XX：UseConcMarkSweepGC &指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server
&7. UseFastAccessorMethods &get,set 方法转成本地代码。
&8. UseCMSCompactAtFullCollection 在使用 concurrent gc 的情况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减少。 建议增加. &9. UseCMSInitiatingOccupancyOnly &仅仅使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC & & & 网上建议：查了很多文章，发现引起promotion failed错误的原因是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，所以执行Full GC-XX:CMSInitiatingOccupancyFraction=70 &CMS堆上，使用70％后开始CMS收集，表示年老代占到约70%时就开始执行CMS，这样就不会出现Full GC了。建议增加. &11. UseCompressedOops 指针压缩，在64位HotSpot中使用32位指针，默认64位会比32位的内存使用多出1.5倍，启用CompressOops后，会压缩的对象：
& & &每个Class的属性指针（静态成员变量） & & &每个对象的属性指针 & & &普通对象数组的每个元素指针 & & &比如指向PermGen的Class对象指针，本地变量，堆栈元素，入参，返回值，NULL指针不会被压缩建议增加. &12. ReduceInitialCardMarks &避免java 6 中CMS的一个bug,导致jvm crash。 该bug在Java6 update25中得到修复 建议增加.个人经验理解也许不一定正确：增大年轻代大小后将会减少年老代大小，将其比例值调到差不多1：1参考值为好； 整个jvm堆内存大小Xmx分配：去除给系统及其它服务所需的内存值后的90%。Xmx和Xms设置一样即可。倘若系统硬件资源不多，因为内存分配的不足，回收的频率相对高了，tomcat所消耗CPU资源就多了，系统负载就上去了。 此时最简单的办法扩增CPU核数或内存。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)