一、Java应用服务器

Tomcat、Nginx、Resin、等多种应用服务器，虽然JVM做为容器，提供的是一个Java Web的运行时环境，以支持Servlet/JSP等等这些内容的运行但是我们都很清楚，其本质上是还是一个Java应用程序。现在有哪些java应用服务器呢？商业的有BEA Weblogic Server、IBM Websphere Application Server、Oracle Application Server、Sybase EAServer。免费开源的java应用服务器有Tomcat、jboss、resin（百度、人人网、搜狗）、Geronimo等。

二、学习JVM调优及JVM区域

运维人员需要会一些JVM调优，为什么运维要了解一些jvm调优的知识，为以后的的运维工作更轻松。学习JVM的调优，主要有两个方面考虑：内存大小配置和垃圾回收算法选择。当然，确切的说，这两点并不互相独立，内存的大小配置也会影响垃圾回收的执行效率。为什么要学习JVM调优? 每次对于容器（这里容器值得是java应用服务器，如：resin、weblogic）的启动运行，都是把这个Java程序跑起来，来实现Web容器的能力。做为一类“特殊”的Java应用程序，和任务其他的java应用一样，需要使用到JVM，会有堆，会使用到垃圾回收，会涉及到不同的堆分区比例... 因此在对Web容器的调优中必不可少的是对于JVM的调优。

JVM区域总体分两类，heap区和非heap区。 heap区又分为： Eden Space（伊甸园）、 Survivor Space(幸存者区)、 Old Gen（老年代）。非heap区又分： Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(Java虚拟机栈)、Local Method Statck(本地方法栈)。

Eden Space字面意思是伊甸园，对象被创建的时候首先放到这个区域，进行垃圾回收后，不能被回收的对象被放入到空的survivor区域。

Survivor Space幸存者区，用于保存在eden space内存区域中经过垃圾回收后没有被回收的对象。Survivor有两个，分别为To Survivor、 From Survivor，这个两个区域的空间大小是一样的。执行垃圾回收的时候Eden区域不能被回收的对象被放入到空的survivor（也就是To Survivor，同时Eden区域的内存会在垃圾回收的过程中全部释放），另一个survivor（即From Survivor）里不能被回收的对象也会被放入这个survivor（即To Survivor），然后To Survivor 和 From Survivor的标记会互换，始终保证一个survivor是空的。 
Eden Space和Survivor Space都属于新生代，新生代中执行的垃圾回收被称之为Minor GC（因为是对新生代进行垃圾回收，所以又被称为Young GC），每一次Young GC后留下来的对象age加1。

注：GC为Garbage Collection，垃圾回收。

Old Gen老年代，用于存放新生代中经过多次垃圾回收仍然存活的对象，也有可能是新生代分配不了内存的大对象会直接进入老年代。经过多次垃圾回收都没有被回收的对象，这些对象的年代已经足够old了，就会放入到老年代。

当老年代被放满的之后，虚拟机会进行垃圾回收，称之为Major GC。由于Major GC除并发GC外均需对整个堆进行扫描和回收，因此又称为Full GC。

heap区即堆内存，整个堆大小=年轻代大小 + 老年代大小。堆内存默认为物理内存的1/64(<1GB)；默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以通过MinHeapFreeRatio参数进行调整；默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以通过MaxHeapFreeRatio参数进行调整。

下面我们来认识下非堆内存（非heap区） 
Code Cache代码缓存区，它主要用于存放JIT所编译的代码。CodeCache代码缓冲区的大小在client模式下默认最大是32m，在server模式下默认是48m，这个值也是可以设置的，它所对应的JVM参数为ReservedCodeCacheSize 和 InitialCodeCacheSize，可以通过如下的方式来为Java程序设置。

-XX:ReservedCodeCacheSize=128m

CodeCache缓存区是可能被充满的，当CodeCache满时，后台会收到CodeCache is full的警告信息，如下所示： 
“CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space?

注：JIT编译器是在程序运行期间，将Java字节码编译成平台相关的二进制代码。正因为此编译行为发生在程序运行期间，所以该编译器被称为Just-In-Time编译器。

Perm Gen全称是Permanent Generation space，是指内存的永久保存区域，因而称之为永久代。这个内存区域用于存放Class和Meta的信息，Class在被 Load的时候被放入这个区域。因为Perm里存储的东西永远不会被JVM垃圾回收的，所以如果你的应用程序LOAD很多CLASS的话，就很可能出现PermGen space错误。默认大小为物理内存的1/64。

 三、内存大小配置

    内存大小配置，最主要做的有：确定内存占用的总大小和确定内存中各个代的大小划分。

    所谓内存大小的占用，是指应用程序启动后稳定运行一小段时间时，观察到的内存占用情况。以 HotSpot 虚拟机为例，Java 堆主要有三个空间：新生代、老年代和永久代。

    根据不同应用的特别，观察应用对于内存的占用，如果有大量的临时对象，不会重复使用，则可以调整 New Gen， 这样这些临时对象就在新生代创建完成，并在 Minor GC 产生时被回收，这样较短生存活的对象不会晋升到老年代，从而可以避免垃圾堆集产生 Full GC。 理想状态下，短期存活的对象都只在新生代完成生命周期，被费时劲少的。Minor GC  回收完成， 而长期存活，将会多次使用的在多次回收之后晋升到老年代， 最终经过 Full GC 完成生命周期。这里涉及到关于内存大小的调整参数有：

-Xms

-Xmx

    这两个参数用于配置 heap 的起始大小和最大值。这里需要经过观察，找一个合适的值，设置太大会导致内存浪费，同时也会导致垃圾回收耗时太长。对于 Tomcat 来说，一般都会将初始值和最大值设置为相同值，这样就避免在初始内存不足时触发 Full GC 来进行扩展内存。

设定 heap 大小之后，要根据对象生命周期的特征，来调整新生代与老年代的大小比例。涉及到的参数有：

-XX:NewSize

-XX:NewRatio

-XX:MaxNewSize

-Xmn

    第一个是直接设置新生代初始大小，第二个是设置比例(Ratio)。太高或太低都会导致 GC 不能高效的工作。毕竟 Minor GC 也是要耗时的。最后一个设置新生代的初始值和最大值相同，堆空间的变化不影响其值。

对于使用了大量第三方类库的应用来说，会加载许多框架依赖的类，使用过程中可能会遇到因为Perm Gen 不足产生的 OOM，这种情况可以通过观察稳定状态下 Perm 区的占用，再通过参数设置。

-XX:PermSize

-XX:MaxPermSize

-XX:MaxMetaspaceSize

    一个会设置Perm区的初始大小，第二个用于设置Perm 区的最大值。在Java 8的时候， Perm 区被移除，改为Metaspace，不过如果遇到类似的OOM,依然可以调整其大小。

此外，对于使用大量线程的应用，也可以配置 -Xss，主要用于设置单个线程的stack 大小。注意，是单个的大小，因此设置值越大，会占用越大，可用的线程数也就越少。

这里的配置一般对于-X开始的可以直接在后面用数字加单位，而-XX的则需要等号后数字再加单位，例如：

java -Xms100m -Xmx200m -XX:PermSize=300m

    这里数字后的单可以是m,g,k代表计算机中的不同单位。

那我们前面一直在说根据不同的应用，观察分析设置堆的大小，堆的各个代的大小，那具体观察什么呢？我们一般在JVM的配置中增加一些打印 GC 日志的选项，配置方式和上面的类似，这样在 GC 产生时，会打印出各个代占用的大小，具体触发时间等。推荐的配置有以下几个：

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

    -Xloggc:<文件名>

-XX:PrintGCDateStamps  

    第一个和第四个选项可以任选一个，第一个打印自JVM启动以来的时间，一般也称为uptime, 第四个打印的是系统当前日期和时间。

四、垃圾回收算法

     垃圾回收的瓶颈

　　传统分代垃圾回收方式，已经在一定程度上把垃圾回收给应用带来的负担降到了最小，把应用的吞吐量推到了一个极限。但是他无法解决的一个问题，就是Full GC所带来的应用暂停。在一些对实时性要求很高的应用场景下，GC暂停所带来的请求堆积和请求失败是无法接受的。这类应用可能要求请求的返回时间在几百甚至几十毫秒以内，如果分代垃圾回收方式要达到这个指标，只能把最大堆的设置限制在一个相对较小范围内，但是这样有限制了应用本身的处理能力，同样也是不可接受的。

　　分代垃圾回收方式确实也考虑了实时性要求而提供了并发回收器，支持最大暂停时间的设置，但是受限于分代垃圾回收的内存划分模型，其效果也不是很理想。

为了达到实时性的要求（其实Java语言最初的设计也是在嵌入式系统上的），一种新垃圾回收方式呼之欲出，它既支持短的暂停时间，又支持大的内存空间分配。可以很好的解决传统分代方式带来的问题。

         增量收集的演进

　　增量收集的方式在理论上可以解决传统分代方式带来的问题。增量收集把对堆空间划分成一系列内存块，使用时，先使用其中一部分（不会全部用完），垃圾收集时把之前用掉的部分中的存活对象再放到后面没有用的空间中，这样可以实现一直边使用边收集的效果，避免了传统分代方式整个使用完了再暂停的回收的情况。

　　当然，传统分代收集方式也提供了并发收集，但是他有一个很致命的地方，就是把整个堆做为一个内存块，这样一方面会造成碎片（无法压缩），另一方面他的每次收集都是对整个堆的收集，无法进行选择，在暂停时间的控制上还是很弱。而增量方式，通过内存空间的分块，恰恰可以解决上面问题。

        Garbage Firest（G1）

　　这部分的内容主要参考这里，这篇文章算是对G1算法论文的解读。我也没加什么东西了。

         目标

　　从设计目标看G1完全是为了大型应用而准备的。

支持很大的堆

         高吞吐量

  -- 支持多CPU和垃圾回收线程

  -- 在主线程暂停的情况下，使用并行收集

  -- 在主线程运行的情况下，使用并发收集

    实时目标：可配置在N毫秒内最多只占用M毫秒的时间进行垃圾回收

　　当然G1要达到实时性的要求，相对传统的分代回收算法，在性能上会有一些损失。

算法详解

图1 G1收集器

         G1可谓博采众家之长，力求到达一种完美。他吸取了增量收集优点，把整个堆划分为一个一个等大小的区域（region）。内存的回收和划分都以region为单位；同时，他也吸取了CMS的特点，把这个垃圾回收过程分为几个阶段，分散一个垃圾回收过程；而且，G1也认同分代垃圾回收的思想，认为不同对象的生命周期不同，可以采取不同收集方式，因此，它也支持分代的垃圾回收。为了达到对回收时间的可预计性，G1在扫描了region以后，对其中的活跃对象的大小进行排序，首先会收集那些活跃对象小的region，以便快速回收空间（要复制的活跃对象少了），因为活跃对象小，里面可以认为多数都是垃圾，所以这种方式被称为Garbage First（G1）的垃圾回收算法，即：垃圾优先的回收。

　　回收步骤：

    初始标记（Initial Marking）

G1对于每个region都保存了两个标识用的bitmap，一个为previous marking bitmap，一个为next marking bitmap，bitmap中包含了一个bit的地址信息来指向对象的起始点。

　　开始Initial Marking之前，首先并发的清空next marking bitmap，然后停止所有应用线程，并扫描标识出每个region中root可直接访问到的对象，将region中top的值放入next top at mark start（TAMS）中，之后恢复所有应用线程。

　　触发这个步骤执行的条件为：

G1定义了一个JVM Heap大小的百分比的阀值，称为h，另外还有一个H，H的值为(1-h)*Heap Size，目前这个h的值是固定的，后续G1也许会将其改为动态的，根据jvm的运行情况来动态的调整，在分代方式下，G1还定义了一个u以及soft limit，soft limit的值为H-u*Heap Size，当Heap中使用的内存超过了soft limit值时，就会在一次clean up执行完毕后在应用允许的GC暂停时间范围内尽快的执行此步骤；

　  在pure方式下，G1将marking与clean up组成一个环，以便clean up能充分的使用marking的信息，当clean up开始回收时，首先回收能够带来最多内存空间的regions，当经过多次的clean up，回收到没多少空间的regions时，G1重新初始化一个新的marking与clean up构成的环。

并发标记（Concurrent Marking）

　　按照之前Initial Marking扫描到的对象进行遍历，以识别这些对象的下层对象的活跃状态，对于在此期间应用线程并发修改的对象的以来关系则记录到remembered set logs中，新创建的对象则放入比top值更高的地址区间中，这些新创建的对象默认状态即为活跃的，同时修改top值。

    最终标记暂停（Final Marking Pause）

　　当应用线程的remembered set logs未满时，是不会放入filled RS buffers中的，在这样的情况下，这些remebered set logs中记录的card的修改就会被更新了，因此需要这一步，这一步要做的就是把应用线程中存在的remembered set logs的内容进行处理，并相应的修改remembered sets，这一步需要暂停应用，并行的运行。

存活对象计算及清除（Live Data Counting and Cleanup）

　　值得注意的是，在G1中，并不是说Final Marking Pause执行完了，就肯定执行Cleanup这步的，由于这步需要暂停应用，G1为了能够达到准实时的要求，需要根据用户指定的最大的GC造成的暂停时间来合理的规划什么时候执行Cleanup，另外还有几种情况也是会触发这个步骤的执行的：

         G1采用的是复制方法来进行收集，必须保证每次的”to space”的空间都是够的，因此G1采取的策略是当已经使用的内存空间达到了H时，就执行Cleanup这个步骤；

        对于full-young和partially-young的分代模式的G1而言，则还有情况会触发Cleanup的执行，full-young模式下，G1根据应用可接受的暂停时间、回收young regions需要消耗的时间来估算出一个yound regions的数量值，当JVM中分配对象的young regions的数量达到此值时，Cleanup就会执行；partially-young模式下，则会尽量频繁的在应用可接受的暂停时间范围内执行Cleanup，并最大限度的去执行non-young regions的Cleanup。

　　以后JVM的调优或许跟多需要针对G1算法进行调优了。

五、常见配置汇总

堆设置

-Xms：初始堆大小

-Xmx：最大堆大小

-XX:NewSize=n：设置年轻代大小

-XX:NewRatio=n：设置年轻代和年老代的比值。如：为3，表示年轻代与年老代比值为1：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数。并行收集线程数。

六、JVM调优案例

     堆大小设置

     年轻代的设置很关键

    JVM中最大堆大小有三方面限制：相关操作系统的数据模型（32-bit 还是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。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一般固定大小为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区进行多次复制，这样可以增加对象在年轻代的存活时间，增加在年轻代被回收的概率。

    回收器选择

    JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动的时候加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。

    吞吐量优先的并行收集器

    如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学计算和后台处理等。

    典型配置：

    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  -Xms时的停顿时间。适用于应用服务器、电信领域等。

    3550  -Xmn2g  -Xss128k  -XX:ParallelGCThreads=20  -XX:+UseConcMarkSweepGC  -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。

-XX:+UseParNewGC：设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。     

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

-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片。

七、调优的方法

    JVM调优工具

    Jconsole、JProfile、VisuaIVM

    Jconsole：JDK自带，功能简单，但是可以在系统有一定负荷情况下使用。对垃圾回收算法有很详细的跟踪。

    JProfile：商业软件，需要付费。功能强大。

    VisuaIVM：jdk自带，功能强大，与JProfiler类似。推荐

    如何调优

    观察内存释放情况、集合类检查、对象树

堆信息查看

图2 查看堆信息可查看堆空间大小分配（年轻代、年老代、持久代分配）。

JVM调优工具

https://my.oschina.net/feichexia/blog/196575

http://blog.csdn.net/zhoudaxia/article/details/26956831

 提供即时的垃圾回收功能。

　　垃圾监控（长时间监控回收情况）。

图3 堆内类和对象信息

　　查看堆内类、对象信息查看：数量、类型等。

图4 对象引用情况

    对象引用情况查看。 
　　有了堆信息查看方面的功能，我们一般可以顺利解决以下问题：

-- 年老代年轻代大小划分是否合理

-- 内存泄漏

-- 垃圾回收算法设置是否合理

 线程监控

图5 线程监控信息

　　线程信息监控：系统线程数量。

　　线程状态监控：各个线程都处在什么样的状态下。

图6 线程转储信息

Dump线程详细信息：查看线程内部运行情况。

死锁检查 。

 热点分析

图7 热点分析

CPU热点：检查系统哪些方法占用的大量CPU时间。

　　内存热点：检查哪些对象在系统中数量最大（一定时间内存活对象和销毁对象一起统计）。

　　这两个东西对于系统优化很有帮助。我们可以根据找到的热点，有针对性的进行系统的瓶颈查找和进行系统优化，而不是漫无目的的进行所有代码的优化。

    快照

　　快照是系统运行到某一时刻的一个定格。在我们进行调优的时候，不可能用眼睛去跟踪所有系统变化，依赖快照功能，我们就可以进行系统两个不同运行时刻，对象（或类、线程等）的不同，以便快速找到问题。

　　举例说，我要检查系统进行垃圾回收以后，是否还有该收回的对象被遗漏下来的了。那么，我可以在进行垃圾回收前后，分别进行一次堆情况的快照，然后对比两次快照的对象情况。

         内存泄漏检

　　内存泄漏是比较常见的问题，而且解决方法也比较通用，这里可以重点说一下，而线程、热点方面的问题则是具体问题具体分析了。

　　内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。

　　内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。

　　需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）。

    年老代堆空间被占满

　　异常： java.lang.OutOfMemoryError: Javaheap space

　　说明：

图8  堆空间慢慢消耗尽

　　这是最典型的内存泄漏方式，简单说就是所有堆空间都被无法回收的垃圾对象占满，虚拟机无法再在分配新空间。

　　如上图所示，这是非常典型的内存泄漏的垃圾回收情况图。所有峰值部分都是一次垃圾回收点，所有谷底部分表示是一次垃圾回收后剩余的内存。连接所有谷底的点，可以发现一条由底到高的线，这说明，随时间的推移，系统的堆空间被不断占满，最终会占满整个堆空间。因此可以初步认为系统内部可能有内存泄漏。（上面的图仅供示例，在实际情况下收集数据的时间需要更长，比如几个小时或者几天）

　　解决：

　　这种方式解决起来也比较容易，一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点。

    持久代被占满

　　异常：java.lang.OutOfMemoryError: PermGen space

　　说明：

Perm空间被占满。无法为新的class分配存储空间而引发的异常。这个异常以前是没有的，但是在Java反射大量使用的今天这个异常比较常见了。主要原因就是大量动态反射生成的类不断被加载，最终导致Perm区被占满。

　　更可怕的是，不同的classLoader即便使用了相同的类，但是都会对其进行加载，相当于同一个东西，如果有N个classLoader那么他将会被加载N次。因此，某些情况下，这个问题基本视为无解。当然，存在大量classLoader和大量反射类的情况其实也不多。

　　解决：

1. -XX:MaxPermSize=16m

2. 换用JDK。比如JRocket。

    堆栈溢出

　　异常：java.lang.StackOverflowError

　　说明：这个就不多说了，一般就是递归没返回，或者循环调用造成

     线程堆栈满

　　异常：Fatal: Stack size too small

　　说明：java中一个线程的空间大小是有限制的。JDK5.0以后这个值是1M。与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上面异常。

　　解决：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代码部分是否有造成泄漏的部分。

    系统内存被占满

　　异常：java.lang.OutOfMemoryError: unable to create new native thread

　　说明：

　　这个异常是由于操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。

　　分配给Java虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内存固定时，分配给Java虚拟机的内存越多，那么，系统总共能够产生的线程也就越少，两者成反比的关系。同时，可以通过修改-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数。

　　解决：

1. 重新设计系统减少线程数量。

2. 线程数量不能减少的情况下，通过-Xss减小单个线程大小。以便能生产更多的线程。

八、JVM调优经验总结

年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择

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

1.并发垃圾收集信息

2.持久代并发收集次数

3.传统GC信息

4.花在年轻代和年老代回收上的时间比例减少年轻代和年老代花费的时间，一般会提高应用的效率

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

较小堆引起的碎片问题

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

-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。        

-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。

JVM调优知识