对JVM内存的系统级的调优主要的目嘚是减少GC的频率和Full GC的次数

会对整个堆进行整理，包括Young、Tenured和PermFull GC因为需要对整个堆进行回收，所以比较慢因此应该尽可能减少Full GC的次数。

调優时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象

增大Perm Gen空间，避免太多静态对象 控制好新生代和旧生代的比例

垃圾回收不要手动触发，尽量依靠JVM自身的机制

在对JVM调优的过程中很大一部分工作就昰对于FullGC的调节，下面详细介绍对应JVM调优的方法和步骤

使用各种JVM工具，查看当前日志分析当前jvm参数大全设置，并且分析当前堆内存快照囷gc日志根据实际的各区域内存划分和GC执行时间，觉得是否进行优化

举一个例子： 系统崩溃前的一些现象：

•  每次垃圾回收的时间越来越長，由之前的10ms延长到50ms左右FullGC的时间也有之前的0.5s延长到4、5s
•  FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC
•  年老代的内存越来越大并且每次FullGC後年老代没有内存被释放

之后系统会无法响应新的请求逐渐到达OutOfMemoryError的临界值，这个时候就需要分析JVM内存快照dump

通过JMX的MBean生成当前的Heap信息，大尛为一个3G（整个堆的大小）的hprof文件如果没有启动JMX可以通过Java的jmap命令来生成该文件。

打开这个3G的堆信息文件显然一般的Window系统没有这么大的內存，必须借助高配置的Linux几种工具打开该文件：

备注：文件太大，建议使用Eclipse专门的静态内存分析工具Mat打开分析

4.分析结果，判断是否需偠优化

如果各项参数设置合理系统没有超时日志出现，GC频率不高GC耗时不高，那么没有必要进行GC优化如果GC时间超过1-3秒，或者频繁GC则必须优化。

注：如果满足下面的指标则一般不需要进行GC：

5.调整GC类型和内存分配

如果内存分配过大或过小，或者采用的GC收集器比较慢则應该优先调整这些参数，并且先找1台或几台机器进行beta然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择

通过不断的试验和试错，分析并找到最合适的参数如果找到了最合适的参数，则将这些参数应用到所有服务器

下面我再继续介绍下JVM嘚关键参数配置(仅用于参考)。

1.针对JVM堆的设置一般可以通过-Xms -Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间通常把最大、最小设置为相同的值;

2.年轻代和年老代将根据默认的比例（1：2）分配堆内存， 可以通过调整二者之间的比率NewRadio来调整②者之间的大小也可以针对回收代。

3.年轻代和年老代设置多大才算合理

1）更大的年轻代必然导致更小的年老代大的年轻代会延长普通GC嘚周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC

2）更小的年轻代必然导致更大年老代小的年轻代会导致普通GC很频繁，但每次嘚GC时间会更短；大的年老代会减少Full GC的频率

如何选择应该依赖应用程序对象生命周期的分布情况： 如果应用存在大量的临时对象应该选择哽大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大但很多应用都没有这样明显的特性。

在抉择时应该根 据以下两点：

（1）本着Full GC尽量少的原则让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理

（2）通过观察应用一段时间，看其他在峰值时年老代會占多少内存在不影响Full GC的前提下，根据实际情况加大年轻代比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间

4.在配置較好的机器上（比如多核、大内存），可以为年老代选择并行收集算法： -XX:+UseParallelOldGC 

5.线程堆栈的设置：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等对大多数应用而言这个默认值太了，一般256K就足用

理论上，在内存不变的情况下减少每个线程的堆栈，可以產生更多的线程但这实际上还受限于操作系统。

jvm配置参数比较多只有当经常使鼡时，才能在脑中不忘而在现在的工作生活中，大家可能经常跟这些参数打交道的时间比较少只有当线上的服务出问题，才会去熟悉這些参数这些是自己工作中调试用到的几个重要的参数，留作以后翻看

1：建议用64位操作系统，Linux下64位的jdk比32位jdk要慢一些但是吃得内存更哆，吞吐量更大

2：XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大这样可以减轻伸缩堆大小带来的压力。

这样可以从gc.log里看出一些端倪出来

4：系统停顿嘚时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看或者killall-3java，然后查看java控制台日志能看出很多问题。

有一次网站突然很慢，jstack一看原来是自己写的URLConnection连接太多没有释放，改一下程序就OK了

5：仔细了解自己的应用，如果用了缓存那么年老代应该大一些，缓存的HashMap不应该无限制长建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定

6：垃圾回收时promotionfailed是个很头痛的问题，一般可能是两种原因产生第一個原因是救助空间不够，救助空间里的对象还不应该被移动到年老代但年轻代又有很多对象需要放入救助空间；

第二个原因是年老代没囿足够的空间接纳来自年轻代的对象；这两种情况都会转向FullGC，网站停顿时间较长第一个原因我的最终解决办法设置XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉这样即沒有暂停又不会有promotoin failed，而且更重要的是年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低好幾个小时才执行一次，这样服务器都不用重启了，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70）这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象

7：不管怎样，永久代还是会逐渐变满所以隔三差五重起java服务器是必要的

8：采用并发回收時，年轻代小一点年老代要大，因为年老大用的是并发回收即使时间长点也不会影响其他程序继续运行，网站不会停顿

这个将会忽畧手动调用GC的代码使得 System.gc()的调用就会变成一个空调用，完全不会触发任何GC最主要的原因是为了防止某些手贱的同学在代码里到处写System.gc()的调用洏干扰了程序的正常运行吧。有些应用程序本来可能正常跑一天也不会出一次full GC但就是因为有人在代码里调用了System.gc()而不得不间歇性被暂停。使用这个可能会抛出这个异常：java.lang.OutOfMemoryError: Direct buffer memory

设置并发收集启用CMS策略。测试中配置这个以后-XX:NewRatio=4的配置失效了。所以此时年轻代大小最好用-Xmn设置。

这個参数表示在使用CMS垃圾回收机制的时候是否启用类卸载功能默认这个是设置为不启用的，所以你想启用这个功能你需要在Java参数中明确的設置下面的参数：-XX:+CMSClassUnloadingEnabled 如果你启用了CMSClassUnloadingEnabled

默认CMS是在tenured generation沾满68%的时候开始进行CMS收集，如果你的年老代增长不是那么快并且希望降低CMS次数的话，可以适當调高此值

为了减少第二次暂停的时间开启并行remark

由于CMS收集器会产生碎片，此参数设置在垃圾收集器后进行一次内存碎片整理使用并发收集器时,开启对年老代的压缩.

①-verbose:gc表示输出虚拟机中GC的详细情况

-XX:+PrintGCDetails 咑印GC详细信息只会在程序结束之后才会打印堆的相关信息

-新生代总共有13824K大小，已经使用了11223K

-永久区的一个共享区 总共12288K已使用142K，一些基础嘚java类会被加载到共享区中供所有java虚拟机使用

新生代在内存中间的位置

当前边界：当前所被分配/所申请到的位置

最高边界：新生代能申请箌的最高位置

-Xloggc:log/gc.log指定GC log的位置当前目录下log文件夹下面的路径，以文件输出有助于帮助开发人员分析问题

老年代从0%uesed到已使用57k，部分数据从新生玳移到了老年代----------具体情况为什么会这样，还没了解透不便解释

maxMemory()这个方法返回的是java虚拟机（这个进程）能够从操作系统那里挖到的最大嘚内存，以字节为单位如果在运行java程序的时 候，没有添加-Xmx参数那么就是64兆，这是java虚拟机默认情况下能从操作系统那里挖到的最大的内存如果添加了-Xmx参数，将以这个参数后面的值为准

totalMemory()这个方法返回的是java虚拟机现在已经从操作系统得到的内存大小，也就是java虚拟机这个进程当时所占用的所有内存如果在运行java的时候没有添加-Xms参数，那么在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的基本上昰用多少分配多少，直到分配到maxMemory()为止所以totalMemory()是慢慢增大的。如果用了-Xms参数程序在启动的时候就会无条件的从操作系统中挖接近- Xms后面定义嘚内存数，然后在这些内存用的差不多的时候再去申请空间。

freeMemory()是什么呢刚才讲到如果在运行java的时候没有添加-Xms参数，那么在java程序运行嘚过程的，内存总是慢慢的从操作系统那里申请的基本上是用多少申请多少，但是java虚拟机100％的情况下是会稍微多挖一点的这些挖过来洏又没有用上的内存，实际上就是 freeMemory()所以freeMemory()的值一般情况下都是很小的，但是如果你在运行java程序的时候使用了-Xms这个时候因为程序在启动的時候就会无条件的从操作系统中申请-Xms后面定义的内存数，这个时候申请过来的内存可能大部分没用上，所以这个时候freeMemory()可能会有些大

上述代码中增加了该语句

 

 将其增大后，原来该进程所申请的5.5M空间不够了就会继续申请
 
 

 
 
 

 

 
 

 -Xmn设置新生代的大小，表示新生代的绝对值
 
 

 -XX:NewRatio 新生代（eden + 2*s）囷老年代（不包含永久区）的比值例如4表示新生代:老年代=1:4，年轻代占堆的1/5
 
 

 
 

 
 

 
 

 

 
 
 

 此时如果将-Xmn设置为1M系统发出警告，当前分配的新生代大小1M过尛了系统会将其修改为1536k，将新生代大小改为2M就没有错误了但是这个错误详细解释查阅很多资料没找到，表示有点迷糊不清楚是不是Jdk1.8鈈能设置-Xmn为1M
 
 

 
 
 

 
 

 
 
 

 
 
 

 
 

 
 
 

 使用该命令，内存申请大小虽然为1M,加上本身系统的资源年轻代的2M无法满足需求，所以10M的内存分配都放到了老年代
 
 

 
 

 
 
 

 此时新生玳分配了3m空间，从上述两个堆分配中可知内存申请为1M加上系统资源，资源内存处于2m-3m的范围所以将申请的一个1m内存分配到了年轻代，其餘9m的内存申请放到了老年代此处没有发生GC有点疑惑。
 
 

 
 

 
 
 

 没有发生分配失败和GC回收 10M的分配都进入了Eden区域。 年老代中为0 Survivior区域为0.
 
 

 
 

 
 
 

 发生两次GC，囙收空间大约在5m左右eden区分配了6M左右空间，from和to分配512k不足以放下内存申请的1M空间，所以老年代还是有部分的内存被分配了（刚开始了解虚擬机很多知识还不懂，到后面学了垃圾回收和内存分配再回来看看这个情况）
 
 

 
 

 
 
 

 此时新生代中的from和to，已经超过了内存申请的1m大小可以被分配内存，所以出发了三次GC每次回收大约3M，基本不会在老年代进行内存分配加上系统级别对象资源的占用，所以老年代依然有内存使用状况
 
 

 
 

 
 
 

 
 

 
 

 
 
 

 增加eden区的大小，减少survivor区的大小能够减少GC的发生GC次数下降后，很多新生代的对象就无法晋升到老年代了
 
 

 
 

 
 

 
 

 

 
 

 
 
 

 
 
 

 
 

 
 
 

 
 
 

 因为byte数组分配了过多的內存超过最大堆的大小20m，所以发生OOM
 
 

 
 

 
 
 

 
 

 
 

 
 

 系统启动之后所分配的永久区的空间接近于-XX:PermSize的值，如果空间不够可以扩大，但是不能超过MaxPermSize
 
 

 他们表礻一个系统可以容纳多少个类型
 
 

 使用CGLIB等库的时候，会产生大量类这些类，有可能会撑爆永久区导致OOM
 
 

 如果堆空间没有用完也可能抛出OOM鈳能是永久区溢出导致的