服务器内存性能调优

一、Linux内存

在Linux下面，我们常用top命令来查看系统进程，top也能显示系统内存。我们常用的Linux下查看内容的专用工具是free命令。

Linux下内存查看命令free详解：

在Linux下查看内存我们一般用free命令：

$ free
             total       used       free     shared    buffers     cached
Mem:       3266180    3250004      16176          0     110652    2668236
-/+ buffers/cache:     471116    2795064
Swap:      2048276      80160    1968116

下面是对内存查看free命令输出内容的解释：

• total:总计物理内存的大小。
• used:已使用多大。
• free:可用有多少。
• Shared:多个进程共享的内存总额。
• Buffers/cached:磁盘缓存的大小。

第三行(-/+ buffers/cached):

• used:已使用多大。
• free:可用有多少。

第四行就不多解释了。

-/+ buffers/cache含义与区别：

第二行(mem)的used/free与第三行(-/+ buffers/cache) used/free的区别在于使用的角度来看：

• 第二行是从OS的角度来看，因为对于OS，buffers/cached 都是属于被使用，所以他的可用内存是16176KB,已用内存是3250004KB,其中包括，内核（OS）使用+Application(X, oracle,etc)使用的+buffers+cached.
• 第三行所指的是从应用程序角度来看，对于应用程序来说，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读取的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。

所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached。

如上例：

• 2795064=16176+110652+2668236

内存如何进行交换

接下来解释什么时候内存会被交换，以及按什么方交换。 当可用内存少于额定值的时候，就会开会进行交换。如何看额定值：

cat /proc/meminfo

输出为：

$ cat /proc/meminfo
MemTotal:      3266180 kB
MemFree:         17456 kB
Buffers:        111328 kB
Cached:        2664024 kB
SwapCached:          0 kB
Active:         467236 kB
Inactive:      2644928 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      3266180 kB
LowFree:         17456 kB
SwapTotal:     2048276 kB
SwapFree:      1968116 kB
Dirty:               8 kB
Writeback:           0 kB
Mapped:         345360 kB
Slab:           112344 kB
Committed_AS:   535292 kB
PageTables:       2340 kB
VmallocTotal: 536870911 kB
VmallocUsed:    272696 kB
VmallocChunk: 536598175 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB

用free -m查看的结果：

[[email protected] tmp]# free -m
             total       used       free     shared    buffers     cached
Mem:          3189       3173         16          0        107       2605
-/+ buffers/cache:        460       2729
Swap:         2000         78       1921

查看/proc/kcore文件的大小（内存镜像）：

$ ll -h /proc/kcore
-r-------- 1 root root 4.1G Jun 12 12:04 /proc/kcore

备注：

占用内存的测量，测量一个进程占用了多少内存，linux为我们提供了一个很方便的方法，/proc目录为我们提供了所有的信息，实际上top等工具也通过这里来获取相应的信息。

• /proc/meminfo 机器的内存使用信息
• /proc/pid/maps pid为进程号，显示当前进程所占用的虚拟地址。
• /proc/pid/statm 进程所占用的内存

​统计系统中所有进程所占用的内存的方法

一、首先先来看proc中对应的两个文件，/proc/[pid]/status和/proc/[pid]/statm;

/proc/[pid]/statm的显示如下：

$ cat /proc/self/statm
654 57 44 0 0 334 0

 对应的各个参数的含义为：（单位是页，一页为4KB；与status文件中的各个参数相对应）。

与之相对应的文件为：proc/[pid]/status，包含了该进程的基本上所有的有用信息统计。

 

统计系统中所有进程的物理内存使用情况脚本

基本思路：遍历/proc下所有的进程，并提取statm下的第二列数据相加，得到所有进程使用的物理页情况，最终乘以4即内存使用情况（KB为单位），脚本代码如下：

#/bin/bash                                                                                                      
for PROC in `ls  /proc/|grep "^[0-9]"`
do
  if [ -f /proc/$PROC/statm ]; then                     //遍历整个proc下的进程
      TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`  //提取每个进程的statm第二列数据
      RSS=`expr $RSS + $TEP`                            //逐个相加
  fi
done
RSS=`expr $RSS \* 4`                                    //将单位为页转换为KB
echo $RSS"KB"

查看机器可用内存

/proc/28248/>free

total used free shared buffers cached
Mem: 1023788 926400 97388 0 134668 503688
-/+ buffers/cache: 288044 735744
Swap: 1959920 89608 1870312

Linux查看内存及内存使用小结：

我们通过free命令查看机器空闲内存时，会发现free的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。

所以空闲内存=free+buffers+cached=total-used

二、Java堆内存参数设置

1. 堆内存原理

JVM堆内存分为2块：永久空间和堆空间。

• 永久即持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。
• Heap = {Old + NEW = {Eden，from，to}}，Old即年老代（Old Generation），New即年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。

年轻代

所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个伊甸区，2个幸存者区（从到）。

大部分对象在伊甸区中生成。当伊甸区满时，还存活的对象将被复制到幸存者区（两个中的一个），当一个幸存者区满时，此区的存活对象将被复制到另外一个幸存者区，当另一个幸存者区也满了的时候，从前一个幸存者区复制过来的并且此时还存活的对象，将可能被复制到年老代。

2个幸存者区是对称的，没有先后关系，所以同一个幸存者区中可能同时存在从伊甸区复制过来对象，和从另一个幸存者区复制过来的对象;而复制到年老区的只有另一个从幸存者区过来的对象。而且，因为需要交换的原因，幸存者区至少有一个是空的。特殊的情况下，根据程序需要，幸存者区是可以配置为多个的（多于2个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

针对年轻代的垃圾回收即Young GC。

年老代

在年轻代中经历了Ñ次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

针对年老代的垃圾回收即Full GC。

持久代

用于存放静态类型数据，如Java的的的类，方法等。持久代对垃圾回收没有显着影响。但是有些应用可能动态生成或调用一些类，例如休眠CGLIB等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。

所以，当一组对象生成时，内存申请过程如下：

1. JVM会试图为相关的Java的的的对象在年轻代的伊甸园区中初始化一块内存区域。
2. 当伊甸区空间足够时，内存申请结束。否则执行下一步。
3. JVM试图释放在伊甸园区中所有不活跃的对象（年轻的GC）。释放后若伊甸园空间仍然不足以放入新对象，JVM则试图将部分伊甸园区中活跃对象放入幸存者区。
4. 幸存者区被用来作为伊甸园区及年老代的中间交换区域。当年老代空间足够时，幸存者区中存活了一定次数的对象会被移到年老代。
5. 当年老代空间不够时，JVM会在年老代进行完全的垃圾回收（Full GC）。
6. 完全GC后，若幸存者区及年老代仍然无法存放从伊甸区复制过来的对象，则会导致JVM无法在伊甸园区为新生成的对象申请内存，即出现“内存不足”。

2. VM内存管理的机制

堆（Heap）和非堆（Non-heap）内存

按照官方的说法：“Java虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在Java虚拟机启动时创建的。”，“在JVM中堆之外的内存称为非堆内存（Non-heap memory）”。

可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。 

堆内存分配

JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；

空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx 相等以避免在每次GC 后调整堆的大小。

说明：如果-Xmx不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JVM，不是Throwable的，无法用try...catch捕捉。 

非堆内存分配

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。（还有一说：MaxPermSize缺省值和-server -client选项相关，-server选项下默认MaxPermSize为64m，-client选项下默认MaxPermSize为32m。这个我没有实验。）

上面错误信息中的PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。还没有弄明白PermGen space是属于非堆内存，还是就是非堆内存，但至少是属于了。

XX:MaxPermSize设置过小会导致java.lang.OutOfMemoryError: PermGen space 就是内存益出。 

3. 为什么会内存益出？

OOM（“Out of Memory”）异常一般主要有如下2种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError：Javaheapspace

这是最常见的情况，产生的原因可能是：设置的内存参数XMX过小或程序的内存泄露及使用不当问题。

例如循环上万次的字符串处理，创建上千万个对象，在一段代码内申请上百中号甚至上ģ的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序，打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。

2. 持久代溢出，表现为：java.lang.OutOfMemoryError：PermGenspace

通常由于持久代设置过小，动态加载了大量的Java类而导致溢出，解决办法唯有将参数-XX：MaxPermSize参数参数参数调大（一般256米能满足绝大多数应用程序需求）将部分的Java的的类放到容器共享区（例如Tomcat share lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，而这些应用有大量的共享类库。、

1. 这一部分内存用于存放Class和Meta的信息，Class在被 Load的时候被放入PermGen space区域，它和存放Instance的Heap区域不同。 
2. GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS 的话，就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。  

4. JVM参数设置

通过JVM的这些选项：Xms/Xmx/PermSize/MaxPermSize可以牵扯出很多问题，比如性能调优等。

设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

参数的含义：

• -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
• -vmargs：说明后面是VM的参数，所以后面的其实都是JVM的参数了
• -Xms128m：JVM初始分配的堆内存
• -Xmx512m：JVM最大允许分配的堆内存，按需分配
• -XX:PermSize=64M：JVM初始分配的非堆内存
• -XX:MaxPermSize=128M：JVM最大允许分配的非堆内存，按需分配

-Xmn，-XX：NewSize / -XX：MaxNewSize，-XX：NewRatio 3组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么？

如下：

1. 高优先级：-XX：新尺寸/ -XX：MaxNewSize 
2. 中优先级：-Xmn（默认等效-Xmn = -XX：NewSize = -XX：MaxNewSize =？） 
3. 低优先级：-XX：NewRatio 

推荐使用-Xmn参数，原因是这个参数简洁，相当于一次设定NewSize / MaxNewSIze，而且两者相等，适用于生产环境。-Xmn配合-Xms / -Xmx，即可将堆内存布局完成。

-Xmn参数是在JDK 1.4开始支持。

JVM内存限制（最大值）

首先JVM内存限制于实际的最大物理内存，假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。

为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？

通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。所以说设置VM参数导致程序无法启动主要有以下几种原因：

1. 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize；
2. -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，比如当前操作系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里需要说明一点的是，如果你的内存是1024MB，但实际系统中用到的并不可能是1024MB，因为有一部分被硬件占用了。

堆大小设置

JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。

典型设置：

java -Xmx3550m -Xms3550m -Xmn2g-Xss128k

-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0

-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

其他辅助信息参数设置

• -XX：-CITime：打印消耗在JIT编译的时间。
• -XX：错误文件= / hs_err_pid.log：保存错误日志或数据到指定文件中。
• -XX：HeapDumpPath = / java_pid.hprof：指定转储堆内存时的路径。
• -XX：-HeapDumpOnOutOfMemoryError：当首次遭遇内存溢出时卸出此时的堆内存。
• -XX：的OnError =“;”：出现致命错误后运行自定义命令。
• -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：跟踪类的卸载信息。

典型配置：

-XX:+PrintGC

输出形式：
[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails

输出形式：
[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用

输出形式：
11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationConcurrentTime：打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用

输出形式：
Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用

输出形式：
Total time for which application threads were stopped: 0.0468229 seconds

-XX:PrintHeapAtGC：打印GC前后的详细堆栈信息

输出形式：
34.702: [GC {Heap before gc invocations=7:
 def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
 tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
 def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
 tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]

-Xloggc:filename：与上面几个配合使用，把相关日志信息记录到文件以便分析。

关于参数名称等

• 标准参数（ - ），所有JVM都必须支持这些参数的功能，而且向后兼容;例如：
  • -client - 设置JVM使用客户端模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或开发调试;在32位环境下直接运行Java程序默认启用该模式。
  • -server - 设置JVM使服务器模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有64位能力的JDK环境下默认启用该模式。
• 非标准参数（-X），默认JVM实现这些参数的功能，但是并不保证所有JVM实现都满足，且不保证向后兼容;
• 非稳定参数（-XX），此类参数各个JVM实现会有所不同，将来可能会不被支持，需要慎重使用;

5. 垃圾回收器选择

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：设置此选项后，并行收集器会自动调整年轻代伊甸区大小和幸存者区大小的比例，以达成目标系统规定的最低响应时间或者收集频率等指标此参数建议在使用并行收集器时，一直打开。

并发收集器（响应时间优先）

• -XX：+ UseConcMarkSweepGC：即CMS收集，设置年老代为并发收集的.cms收集是JDK1.4后期版本开始引入的新GC算法它的主要适合场景是对响应时间的重要性需求大于对吞吐量的需求，能够承受垃圾回收线程和应用线程共享CPU资源，并且应用中存在比较多的长生命周期对象的的的.cms收集的目标是尽量减少应用的暂停时间，减少全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优于全GC执行。
• -XX：-DisableExplicitGC：不响应System.gc（）的的的代码。
• -XX：+ UseThreadPriorities：启用本地线程优先级API即使生效，不启用  java.lang.Thread.setPriority() 则无效。
• -XX：SoftRefLRUPolicyMSPerMB = 0：软引用对象在最后一次被访问后能存活0毫秒（JVM默认为1000毫秒）。
• -XX：TargetSurvivorRatio = 90：允许90％的幸存者区被占用（JVM默认为50％）提高对于幸存者区的使用率。

吞吐量优先的并行收集器典型配置：

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

• -XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
• -XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

• -XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100

• -XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

       -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

响应时间优先的并发收集器典型配置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

• -XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
• -XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

• -XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
• -XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

6. 常见配置汇总

堆设置

• -Xms:初始堆大小
• -Xmx:最大堆大小
• -XX:NewSize=n:设置年轻代大小
• -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
• -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
• -XX:MaxPermSize=n:设置持久代大小

收集器设置

• -XX:+UseSerialGC:设置串行收集器
• -XX:+UseParallelGC:设置并行收集器
• -XX:+UseParalledlOldGC:设置并行年老代收集器
• -XX:+UseConcMarkSweepGC:设置并发收集器

垃圾回收统计信息

• -XX:+PrintGC
• -XX:+PrintGCDetails
• -XX:+PrintGCTimeStamps
• -Xloggc:filename

并行收集器设置

• -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
• -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
• -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

并发收集器设置

• -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
• -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

7. JVM调优总结

年轻代大小选择：

• 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
• 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择：

1、响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

• 并发垃圾收集信息
• 持久代并发收集次数
• 传统GC信息
• 花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率。

2、吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

较小堆引起的碎片问题：

因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

• -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
• -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

三、内存泄漏判断方法

有时候，内存泄漏不明显，或者怀疑系统有内存泄漏，我们可以通过下面介绍的方法初步确认系统是否存在内存泄漏。

首先在Java命令行中增加-verbose:gc参数，然后重新启动java进程。

当系统运行过程中,JVM进行垃圾回收的时候，会将垃圾回收的日志打印出来，通过分析这些GC日志，我们可以初步判断系统是否存在堆内存泄漏。

8190.813: [GC 164675K->251016K(1277056K), 0.0117749 secs]
8190.825: [Full GC 251016K->164654K(1277056K), 0.8142190 secs]
8191.644: [GC 164678K->251214K(1277248K), 0.0123627 secs]
8191.657: [Full GC 251214K->164661K(1277248K), 0.8135393 secs]
8192.478: [GC 164700K->251285K(1277376K), 0.0130357 secs]
8192.491: [Full GC 251285K->164670K(1277376K), 0.8118171 secs]
8193.311: [GC 164726K->251182K(1277568K), 0.0121369 secs]
8193.323 : [Full GC 251182K->164644K(1277568K), 0.8186925 secs]
8194.156: [GC 164766K->251028K(1277760K), 0.0123415 secs]
8194.169: [Full GC 251028K->164660K(1277760K), 0.8144430 secs]

在这段GC输出中，每一项的含义如下：

我们知道，Java虚拟机的垃圾回收有两种类型： 通GC 在GC信息的输出中，[GC 164726K->251182K(1277568K)，0.0121369 secs]中的"GC"就代表的普通GC，普通GC只回收部分垃圾对象，因此回收完毕后，系统中仍存在大量的垃圾对象 全GC 即FULL GC,在GC信息的输出中，[Full GC 251285K->164670K(1277376K), 0.8118171secs] 的"FULL GC"就代表的完全GC。

完全GC，系统彻底的对垃圾对象进行回收，回收完毕后，垃圾对象所占用的内存得到彻底的回收，此时系统中存在的对象都是真正在使用 的活动对象，这时候的Java内存真实地反映了Java对象所占用的内存的大小。

在分析系统是否存在内存泄漏时，我们关注的是在当时真正有用的对象所占用的内存的大小。如果随着系统的运行，真正的Java对象所占用的内存越来越大，那么基本上能够确认存在内存泄漏（此时要排除系统是否设计了大量的缓存）。因此在做内存泄漏的分析时，只需要分析Full GC的行(非完全垃圾回收，由于并没有将所有的垃圾都回收，因此对我们的分析没有价值)。

以下面的例子为例进行说明：

 

251285K 完全垃圾回收之前Java对象占用的内存大小，这个值包含两部分，一部分是正在使用的Java对象占用的空间，另一部分是垃圾对象占用的空间。JAVA内存泄漏分析和堆内存设置 73。

• 164670K 完全垃圾回收之后Java对象占用的内存大小，这个值是真正的活动Java对象占用 的内存。

• 1277376K 堆的设置最大值。

• 0.8118171 secs 表示本次完全垃圾回收占用的时间。

    判断系统是否存在内存泄漏的依据是：如果系统存在内存泄漏，那么完全垃圾回收完之 的内存值应该持续上升。如果在现场能观察到这个现象，说明系统存在内存泄漏当怀疑 个系统存在内存泄漏的时候，首先使用FULL GC信息对内存泄漏进行一个初步确认，确认统是否存在内存泄漏。只检查完全垃圾回收后的可用内存值是否一直再增大，步骤如下：

首先截取系统稳定运行以后的GC信息（如初始化已经完成），这个非常重要，非稳定运行期的信息无分析价值，因为你无法确认内存的增长是正常的增长还是由于内存泄漏导致的非正常增长。. 过滤出FULL GC的行。只有FULL GC的行才有分析价值。因为完全GC后的内存是当 前Java对象真正使用的内存数量。一般系统会有两种可能：

(a) 如果完全垃圾回收后的内存持续增长32，大有一直增长到Xmx设定值的趋势，那么这个时候基本上就可以断定系统存在内存泄漏。

(b) 如果当前完全垃圾回收后内存增长到一个值之后，又能回落，总体上处于一个动态平衡，那么内存泄漏基本可以排除。 通过如上内存使用趋势分析之后，基本上就能确定系统是否存在堆内存泄漏。

当然这 GC信息分析只能告诉你系统是否存在堆内存泄漏，但具体哪里泄漏，它是无法告诉你的。 存泄漏的的精确定位，是要找到内存泄漏的具体位置，需要借助如下工具/手段之一可以找 真正导致内存泄漏的类或者对象。 

 四、JVM服务参数调优实战

(一) 环境LinuxAS4，resin2.1.17，JDK6.0，2CPU，4G内存，dell2950服务器。

JVM调优之串行垃圾回收

也就是默认配置，完成10万request用时153秒。JVM参数配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms2048M-Xmx2048M-Xmn512M
-XX:PermSize=256M-XX:MaxPermSize=256M 
-XX:MaxTenuringThreshold=7-XX:GCTimeRatio=19 
-Xnoclassgc-Xloggc:log/gc.log
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps";  

这种配置一般在resin启动24小时内似乎没有大问题，网站可以正常访问，但查看日志发现，在接近24小时时，FullGC执行越来越频繁，大约每隔3分钟就有一次FullGC，每次FullGC系统会停顿6秒左右，作为一个网站来说，用户等待6秒恐怕太长了，所以这种方式有待改善。MaxTenuringThreshold=7表示一个对象如果在救助空间移动7次还没有被回收就放入年老代，GCTimeRatio=19表示java可以用5%的时间来做垃圾回收，1/(1+19)=1/20=5%。

JVM调优之并行回收

完成10万request用时117秒，配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xmx2048M  
-Xms2048M-Xmn512M-XX:PermSize=256M-XX:MaxPermSize=256M 
-Xnoclassgc-Xloggc:log/gc.log-XX:+PrintGCDetails  
-XX:+PrintGCTimeStamps-XX:+UseParallelGC-XX:ParallelGCThreads=20 
-XX:+UseParallelOldGC-XX:MaxGCPauseMillis=500 
-XX:+UseAdaptiveSizePolicy-XX:MaxTenuringThreshold=7 
-XX:GCTimeRatio=19";  

并行回收我尝试过多种组合配置，似乎都没什么用，resin启动3小时左右就会停顿，时间超过10秒。也有可能是参数设置不够好的原因，MaxGCPauseMillis表示GC最大停顿时间，在resin刚启动还没有执行FullGC时系统是正常的，但一旦执行FullGC，MaxGCPauseMillis根本没有用，停顿时间可能超过20秒，之后会发生什么我也不再关心了，赶紧重启resin，尝试其他回收策略。

JVM调优之并发回收

完成10万request用时60秒，比并行回收差不多快一倍，是默认回收策略性能的2.5倍，配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M 
-XX:MaxPermSize=256M-XX:+UseConcMarkSweepGC  
-XX:MaxTenuringThreshold=7-XX:GCTimeRatio=19 
-Xnoclassgc-Xloggc:log/gc.log-XX:+PrintGCDetails  
-XX:+PrintGCTimeStamps-XX:+UseCMSCompactAtFullCollection  
-XX:CMSFullGCsBeforeCompaction=0"; 

这个配置虽然不会出现10秒连不上的情况，但系统重启3个小时左右，每隔几分钟就会有5秒连不上的情况，查看gc.log，发现在执行ParNewGC时有个promotionfailed错误，从而转向执行FullGC，造成系统停顿，而且会很频繁，每隔几分钟就有一次，所以还得改善。UseCMSCompactAtFullCollection是表是执行FullGC后对内存进行整理压缩，免得产生内存碎片，CMSFullGCsBeforeCompaction=N表示执行N次FullGC后执行内存压缩。

JVM调优之增量回收

完成10万request用时171秒，太慢了，配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M 
-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7 
-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log  
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xincgc"; 

似乎回收得也不太干净，而且也对性能有较大影响，不值得试。

JVM调优之并发回收的I-CMS模式

和增量回收差不多，完成10万request用时170秒。配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M 
-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7 
-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log  
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps  
-XX:+UseConcMarkSweepGC-XX:+CMSIncrementalMode  
-XX:+CMSIncrementalPacing  
-XX:CMSIncrementalDutyCycleMin=0 
-XX:CMSIncrementalDutyCycle=10-XX:-TraceClassUnloading"; 

采用了sun推荐的参数，回收效果不好，照样有停顿，数小时之内就会频繁出现停顿，什么sun推荐的参数，照样不好使。

JVM调优之递增式低暂停收集器

又叫什么火车式回收，完成10万request用时153秒，配置如下： 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M 
-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7 
-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log  
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+UseTrainGC"; 

该配置效果也不好，影响性能，所以没试。

相比之下，还是并发回收比较好，性能比较高，只要能解决ParNewGC（并行回收年轻代）时的promotionfailed错误就一切好办了，查了很多文章，发现引起promotionfailed错误的原因是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，所以执行FullGC。CMSInitiatingOccupancyFraction=70表示年老代占到约70%时就开始执行CMS，这样就不会出现FullGC了。SoftRefLRUPolicyMSPerMB这个参数也是我认为比较有用的，我觉得没必要等1秒，所以设置成0。配置如下：

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xms2048M  
-Xmx2048M-Xmn512M-XX:PermSize=256M-XX:MaxPermSize=256M 
-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=7 
-XX:GCTimeRatio=19-Xnoclassgc-XX:+DisableExplicitGC  
-XX:+UseParNewGC-XX:+UseConcMarkSweepGC  
-XX:+CMSPermGenSweepingEnabled  
-XX:+UseCMSCompactAtFullCollection  
-XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled  
-XX:CMSInitiatingOccupancyFraction=70 
-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram  
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps  
-XX:+PrintGCApplicationConcurrentTime  
-XX:+PrintGCApplicationStoppedTime  
-Xloggc:log/gc.log"; 

上面这个配置内存上升的很慢，24小时之内几乎没有停顿现象，最长的只停滞了0.8s，ParNewGC每30秒左右才执行一次，每次回收约0.2秒，看来问题应该暂时解决了。

参数不明白的可以上网查，本人认为比较重要的几个参数是：

-Xms-Xmx-XmnMaxTenuringThresholdGCTimeRatioUse
ConcMarkSweepGCCMSInitiatingOccupancyFractionSoftRefLRUPolicyMSPerMB
eclipse中配置JVM参数:-Xmx1024M-Xms1000M-server-XX:PermSize=64M-XX:MaxPermSize=128m

(二) 大型网站服务器案例

承受海量访问的动态的网络应用。

服务器配置：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。此值对系统性能影响较大，太阳官方推荐配置年轻代大小为整个堆的3/8。
• -Xss128k设置较小的线程栈以支持创建更多的线程，支持海量访问，并提升系统性能。
• -XX：SurvivorRatio = 6设置年轻代中Eden区与Survivor区的比值。系统默认是8，根据经验设置为6，则2个幸存者区与1个Eden区的比值为2：6，一个幸存者区占整个年轻代的1/8。
• -XX：ParallelGCThreads = 8配置并行收集器的线程数，即同时8个线程一起进行垃圾回收。此值一般配置为与CPU数目相等。
• -XX：MaxTenuringThreshold = 0设置垃圾最大年龄（在年轻代的存活次数）。如果设置为0的话，则年轻代对象不经过Survivor区直接进入年老代。对于年老代比较多的应用，可以提高效率;如果将此值设置为一个较大值，则年轻代对象会在幸存者区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率根据被海量访问的动态网络应用之特点，其内存要么被缓存起来以减少直接访问数据库，要么被快速回收以支持高并发海量请求，因此其内存对象在年轻代存活多次意义不大，可以直接进入年老代，根据实际应用效果，在这里设置此值为0。
• -XX：+ UseConcMarkSweepGC设置年老代为并发收集.CMS（ConcMarkSweepGC）收集的目标是尽量减少应用的暂停时间，减少完全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堆内存状况。

堆配置：

MinHeapFreeRatio = 40 
MaxHeapFreeRatio = 70 
MaxHeapSize = 1073741824（1024.0MB）
NewSize = 335544320（320.0MB）
MaxNewSize = 335544320（320.0MB）
OldSize = 5439488（5.1875MB）
NewRatio = 2 
SurvivorRatio = 8 
PermSize = 205520896（196.0MB）
MaxPermSize = 205520896（196.0MB）