JVM 内存优化设置
在一些规模稍大的应用中，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.Young
2.Old
3.Permanent
Young保存刚实例化的对象。当该区被填满时，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种GC
1、第一种为单线程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: simsun; COLOR: #464646; "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 128k
jboss性能优化:内存紧张的问题
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 128k
2.修改deploy/jbossweb-tomcat55.sar/service.xml
将maxThreads根据目前的访问量由默认的250降为75，并使用jboss 4默认未写在标准service.xml里面而jboss 3写入了的2个参数:
maxSparseThreads=200，minSparseThreads=100
3.修改oracle-ds.xml将最大连接数有150降为50.
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m或修改catalina.sh
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
2、其次是：java.lang.OutOfMemoryError: PermGen space
原因：
PermGen space的全称是Permanent Generation
space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen
space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage
Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen
space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar,
其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
解决方法：
1. 手动设置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在Java代码“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行： [*]set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m “echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m
catalina.sh下为：
Java代码JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m" JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"另外看到了另外一个帖子，觉得挺好，摘抄如下：
分析java.lang.OutOfMemoryError: PermGen space
发现很多人把问题归因于： spring,hibernate,tomcat，因为他们动态产生类,导致JVM中的permanent heap溢出 。然后解决方法众说纷纭，有人说升级 tomcat版本到最新甚至干脆不用tomcat。还有人怀疑spring的问题，在spring论坛上讨论很激烈，因为spring在AOP时使用 CBLIB会动态产生很多类。
但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？tomcat在Q&A很隐晦的回答了这一点，我们知道这个问题，但这个问题是由一个更基础的问题产生。
于是有人对更基础的JVM做了检查，发现了问题的关键。原来SUN
的JVM把内存分了不同的区，其中一个就是permenter区用来存放用得非常多的类和类描述。本来SUN设计的时候认为这个区域在JVM启动的时候就
固定了，但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，gc根本没办法回收！
对于以上两个问题，我的处理是：
在catalina.bat的第一行增加：
Java代码set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m在catalina.sh的第一行增加：
Java代码JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m