Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个Java虚拟机。
Tomcat的内存溢出本质就是JVM内存溢出，所以在本文开始时，应该先对Java JVM有关内存方面的知识进行详细介绍。
一、Java JVM内存介绍
JVM管理两种类型的内存，堆和非堆。
按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。
堆是在 Java 虚拟机启动时创建的。
”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。
简单来说堆就是Java代码可及的内存，是留给开发人员使用的；
非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、
每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中，它和堆不同，运行期内GC不会释放其空间。
(1). 堆内存分配
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指 定，默认是物理内存的1/4。
默认空余堆内存小于 40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。
因此服务器一般设置-Xms、 -Xmx相等以避免在每次GC 后调整堆的大小。
可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行堆内存设置，一般的要将-Xms和-Xmx选项设置为相同，
而-Xmn为1/4的-Xmx值，建议堆的最大值设置为可用内存的最大值的80%。
初始化堆的大小是JVM在启动时向系统申请的内存的大小。一般而言，这个参数不重要。
但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果JVM启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，JVM就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。
一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时JVM就会提示内存溢出，并且导致应用服务崩溃。
所以，如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
(2). 非堆内存分配
也叫永久保存的区域，用于存放Class和Meta信息,Class在被Load的时候被放入该区域。
它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理。
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
GC不会对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
(3). JVM内存限制(最大值)
首先JVM内存限制于实际的最大物理内存（废话！，呵呵），假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。
简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统 下为2G-3G），
而64bit以上的处理器就不会有限制了。
二、三种内存溢出异常介绍
1. OutOfMemoryError： Java heap space 堆溢出
内存溢出主要存在问题就是出现在这个情况中。当在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。
2. OutOfMemoryError： PermGen space 非堆溢出（永久保存区域溢出）
这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
3. OutOfMemoryError： unable to create new native thread. 无法创建新的线程
这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。这种怪事是因为JVM已经被系统分配了大量的内存（比如1.5G），并且它至少要占用可用内存的一半。
三、Java JVM内存配置
1. JVM内存分配设置的参数有四个
-Xmx Java Heap最大值，默认值为物理内存的1/4；
-Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；
-Xmn Java Heap Young区大小，不熟悉最好保留默认值；
-Xss 每个线程的Stack大小，不熟悉最好保留默认值；
-XX:PermSize：设定内存的永久保存区域；
-XX:MaxPermSize：设定最大内存的永久保存区域；
-XX:PermSize：设定内存的永久保存区域；
-XX:NewSize：设置JVM堆的‘新生代’的默认大小；
-XX:MaxNewSize：设置JVM堆的‘新生代’的最大大小；
2. 如何设置JVM的内存分配
（1）当在命令提示符下启动并使用JVM时（只对当前运行的类Test生效）：
java -Xmx128m -Xms64m -Xmn32m -Xss16m Test
（2）当在集成开发环境下（如eclipse）启动并使用JVM时：
a. 在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）： -vmargs -Xms40m -Xmx256m -vmargs表示以下为虚拟机设置参数，可修改其中的参数值，也可添加-Xmn，-Xss，另外，eclipse.ini内还可以设置非 堆内存，如：-XX:PermSize=56m，-XX:MaxPermSize=128m。
b. 打开eclipse－窗口－首选项－Java－已安装的JRE（对在当前开发环境中运行的java程序皆生效） 编辑当前使用的JRE，在缺省VM参数中输入：-Xmx128m -Xms64m -Xmn32m –Xss16m。
c. 打开eclipse－运行－运行－Java应用程序（只对所设置的java类生效） 选定需设置内存分配的类－自变量，在VM自变量中输入：-Xmx128m -Xms64m -Xmn32m -Xss16m 注：如果在同一开发环境中同时进行了b和c设置，则b设置生效，c设置无效，如： 开发环境的设置为：-Xmx256m，而类Test的设置为：-Xmx128m -Xms64m，则运行Test时生效的设置为： -Xmx256m -Xms64m。
（3）当在服务器环境下（如Tomcat）启动并使用JVM时（对当前服务器环境下所以Java程序生效）：
a. 设置环境变量： 变量名：CATALINA_OPTS 变量值：-Xmx128m -Xms64m -Xmn32m -Xss16m。
b. 打开Tomcat根目录下的bin文件夹，编辑catalina.bat，将其中的%CATALINA_OPTS%（共有四处）替换为：-Xmx128m -Xms64m -Xmn32m -Xss16m。
c. 若没有catalina.bat，只有tomcat.exe,tomcat6w.exe;则可以在启动tomcat6w.exe 后 右键配置--Java--java option 下面输入：
-Xmx256m –Xms64m
也可以找到注册表HKEY_LOCAL_MACHINESOFTWAREApache Software FoundationTomcatService ManagerTomcat6ParametersJavaOptions原值为 -Dcatalina.home="C:ApacheGroupTomcat 6.0" -Djava.endorsed.dirs="C:ApacheGroupTomcat 6.0commonendorsed" -Xrs 加入 -Xms300m -Xmx350m （我的是加入-Xmx350m，tomcat才能启动，加入-Xms300m -Xmx350m反而tomcat都不能启动）重起tomcat服务,设置生效。
3. 查看JVM内存信息
Runtime.getRuntime().maxMemory(); //最大可用内存，对应-Xmx
Runtime.getRuntime().freeMemory(); //当前JVM空闲内存
Runtime.getRuntime().totalMemory(); //当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和
关于maxMemory()，freeMemory()和totalMemory()：maxMemory()为JVM的最大可用内存，可通过-Xmx设置，默认值为物理内存的1/4，设置不能高于计算机物理内存；
totalMemory()为当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和，会随着JVM使用内存的增加而增加；
freeMemory()为当前JVM空闲内存，因为JVM只有在需要内存时才占用物理内存使用，所以freeMemory()的值一般情况下都很小，
而JVM实际可用内存并不等于freeMemory()，而应该等于maxMemory()-totalMemory()+freeMemory()。
4. 实例，以下给出1G内存环境下java jvm 的参数设置参考
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "
大型的web工程，用tomcat默认分配的内存空间无法启动，如果不是在myeclipse中启动tomcat可以对tomcat这样设置：
TOMCAT_HOMEincatalina.bat 中添加这样一句话：
set JAVA_OPTS= -Xmx1024M -Xms512M -XX:MaxPermSize=256m
如果要在myeclipse中启动，上述的修改就不起作用了，可如下设置：
Myeclipse->preferences->myeclipse->servers->tomcat->tomcat×.×->JDK面板中的
Optional Java VM arguments中添加：-Xmx1024M -Xms512M -XX:MaxPermSize=256m
对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。 java -Xms64m -Xmx256m Test -Xms是设置内存初始化的大小 -Xmx是设置最大能够使用内存的大小。
四、JVM内存配置与GC
需要考虑的是Java提供的垃圾回收机制。JVM的堆大小决定了JVM花费在收集垃圾上的时间和频度。
收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。
如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。
如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。
调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。
在基准测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。
如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。
如果垃圾收集成为瓶颈，那么需要指定堆的大小，检查垃圾收集的详细输出，研究垃圾收集参数对性能的影响。
一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。
Java Heap分为3个区：
1.Young 2.Old 3.Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。
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等。
====================================================
这里向大家描述一下如何使用Tomcat配置JVM参数，Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。
您可以选择自己的需要选择不同的操作系统和对应的JDK的版本，但还是推荐您使用Sun公司发布的JDK。
jvm在client模式，进行内存回收时，会停下所有的其它工作，带回收完毕才去执行其它任务，在这期间eclipse就卡住了。
所以适当的增加jvm申请的内存大小来减少其回收的次数甚至不回收，就会是卡的现象有明显改善。
主要通过以下的几个jvm参数来设置堆内存的：
| -Xmx512m | 最大总堆内存，一般设置为物理内存的1/4 |
| -Xms512m | 初始总堆内存，一般将它设置的和最大堆内存一样大，这样就不需要根据当前堆使用情况而调整堆的大小了 |
| -Xmn192m | 年轻带堆内存，sun官方推荐为整个堆的3/8 |
| 堆内存的组成 | 总堆内存 = 年轻带堆内存 + 年老带堆内存 + 持久带堆内存 |
| 年轻带堆内存 | 对象刚创建出来时放在这里 |
| 年老带堆内存 | 对象在被真正会回收之前会先放在这里 |
| 持久带堆内存 | class文件，元数据等放在这里 |
| -XX:PermSize=128m | 持久带堆的初始大小 |
| -XX:MaxPermSize=128m | 持久带堆的最大大小，eclipse默认为256m。如果要编译jdk这种，一定要把这个设的很大，因为它的类太多了。 |
Tomcat配置JVM参数
Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。
您可以选择自己的需要选择不同的操作系统和对应的 JDK的版本（只要是符合Sun发布的Java规范的），但我们推荐您使用Sun公司发布的JDK。
确保您所使用的版本是最新的，因为Sun公司和其它一 些公司一直在为提高性能而对java虚拟机做一些升级改进。
一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。
可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。
可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。
参数 描述
-Xms JVM初始化堆的大小
-Xmx JVM堆的最大值
这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。
一般而言，这个参数不重要。
但是有的应用程序在大负载 的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必 须重复地增加内存来满足使用。
由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。
一般使用数据量较大的应用程序会使用持久对象，内存使用 有可能迅速地增长。
当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。
因此一般建议堆的最大值设置为可用内存的最大值 的80%。
Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。
Windows下，在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下设置：
JAVA_OPTS='-Xms【初始化内存大小】
-Xmx【可以使用的最大内存】'
需要把这个两个参数值调大。例如：
- JAVA_OPTS'-Xms256m-Xmx512m'
表示初始化内存为256MB，可以使用的最大内存为512MB。
另外需要考虑的是Java提供的垃圾回收机制。
虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分 析实际的垃圾收集的时间和频率来调整。
如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。
如果你把堆的大小和内存的需要一致，完全收集就很 快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。
在基准测试的时候，为保证最好的性能，要把堆的 大小设大，保证垃圾收集不在整个基准测试的过程中出现。
如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过3-5秒。
如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详 细输出，研究垃圾收集参数对性能的影响。
一般说来，你应该使用物理内存的80%作为堆大小。
当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾 收集不是并行的。
1：建议用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大。
2：XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力。
3：调试的时候设置一些打印JVM参数，如-XX:+PrintClassHistogram-XX:+PrintGCDetails- XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log，这样可以从gc.log里看出 一些端倪出来。
4：系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall-3java，然后查看java控制台日 志，能看出很多问题。有一次，网站突然很慢，jstack一看，原来是自己写的URLConnection连接太多没有释放，改一下程序就OK了。
5：仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。
6：垃圾回收时promotionfailed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到 年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向FullGC，网站停顿时间 较长。第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536- XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction 为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。
7：不管怎样，永久代还是会逐渐变满，所以隔三差五重起java服务器是必要的，我每天都自动重起。
8：采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿。
我的最终配置如下（系统8G内存），每天几百万pv一点问题都没有，网站没有停顿，2009年网站没有因为内存问题down过机。
$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT
-server-Xms6000M-Xmx6000M-Xmn500M
-XX:PermSize=500M-XX:MaxPermSize=500M
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
-Xnoclassgc
-XX:+DisableExplicitGC
XX:+UseParNewGC-XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=90
-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC
-Xloggc:log/gc.log";
说明一下，-XX:SurvivorRatio=65536，-XX:MaxTenuringThreshold=0就是去掉了救助空间；
-Xnoclassgc禁用类垃圾回收，性能会高一点；
-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能；
-XX:+UseParNewGC，对年轻代采用多线程并行回收，这样收得快；
带CMS参数的都是和并发回收相关的，不明白的可以上网搜索；
CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotionfailed。
在我的应用中 Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500 兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还 剩10%的空间是5500*10%=550兆，所以即使Xmn（也就是年轻代共500兆）里所有对象都搬到年老代里，550兆的空间也足够了，所以只要满 足上面的公式，就不会出现垃圾回收时的promotionfailed；
SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用，官方解释是 softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.
Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap，我觉得没必要等1秒；
网上其他介绍JVM参数的也比较多，估计其中大部分是没有遇到promotionfailed，或者访问量太小没有机会遇到，(Xmx-Xmn)* (100-CMSInitiatingOccupancyFraction)/100>=Xmn这个公式绝对是原创，真遇到 promotionfailed了，还得这么处理。
JVM内存设置原理
默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。
设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。
java-Xms64m-Xmx256mTest
-Xms是设置内存初始化的大小
-Xmx是JVM内存设置中设置最大能够使用内存的大小（最好不要超过物理内存大小）
在weblogic中，可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。简单介绍了JVM内存设置，下面我们看一下JVM内存的调优。
JVM内存的调优
1.Heap设定与垃圾回收
JavaHeap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可以使用-X参数设定，
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。
Xss每个线程的Stack大小
Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
3．硬件环境
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。
如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用[2]。
4．4种GC
第一种为单线程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。