jvm调优

一、JVM 参数配置方法

Tomcat 的启动参数位于安装目录 ${JAVA_HOME}/bin目录下，Linux 操做系统就是 catalina.sh 文件。JAVA_OPTS，就是用来设置 JVM 相关运行参数的变量，还能够在 CATALINA_OPTS 变量中设置。关于这 2 个变量，仍是多少有些区别的：

JAVA_OPTS：用于当 Java 运行时选项“start”、“stop”或“run”命令执行。

CATALINA_OPTS：用于当 Java 运行时选项“start”或“run”命令执行。

为何有两个不一样的变量？它们之间都有什么区别呢？

首先，在启动 Tomcat 时，任何指定变量的传递方式都是相同的，能够传递到执行“start”或“run”命令中，但只有设定在 JAVA_OPTS 变量里的参数被传递到“stop”命令中。对于 Tomcat 运行过程，可能没什么区别，影响的是结束程序，而不是启动程序。

第二个区别是更微妙，其余应用程序也可使用 JAVA_OPTS 变量，但只有在 Tomcat 中使用 CATALINA_OPTS 变量。若是你设置环境变量为只使用 Tomcat，最好你会建议使用 CATALINA_OPTS 变量，而若是你设置环境变量使用其它的 Java 应用程序，例如 JBoss，你应该把你的设置放在JAVA_OPTS 变量中。

二、JVM 参数属性

32 位系统下 JVM 对内存的限制：不能突破 2GB ，那么这时你的 Tomcat 要优化，就要讲究点技巧了，而在 64 位操做系统上不管是系统内存仍是 JVM 都没有受到 2GB 这样的限制。

针对于 JMX 远程监控也是在这里设置，如下为 64 位系统环境下的配置，内存加入的参数以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

CATALINA_OPTS=" -server  -Xms6000M  -Xmx6000M  -Xss512k  -XX:NewSize=2250M  -XX:MaxNewSize=2250M  -XX:PermSize=128M -XX:MaxPermSize=256M   -XX:+AggressiveOpts  -XX:+UseBiasedLocking  -XX:+DisableExplicitGC  -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:MaxTenuringThreshold=31  -XX:+CMSParallelRemarkEnabled  -XX:+UseCMSCompactAtFullCollection  -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods  -XX:+UseCMSInitiatingOccupancyOnly -Duser.timezone=Asia /Shanghai  -Djava.awt.headless= true "

为了看着方便，将每一个参数单独写一行。上面参数好多啊，可能有人写到如今都没见过一个在 Tomcat 的启动命令里加了这么多参数，固然，这些参数只是我机器上的，不必定适合你，尤为是参数后的 value（值）是须要根据你本身的实际状况来设置的。

上述这样的配置，基本上能够达到：

系统响应时间增快；

JVM回收速度增快同时又不影响系统的响应率；

JVM内存最大化利用；

线程阻塞状况最小化。

JVM 经常使用参数详解：

-server：必定要做为第一个参数，在多个 CPU 时性能佳，还有一种叫 -client 的模式，特色是启动速度比较快，但运行时性能和内存管理效率不高，一般用于客户端应用程序或开发调试，在 32 位环境下直接运行 Java 程序默认启用该模式。Server 模式的特色是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境，在具备 64 位能力的 JDK 环境下默认启用该模式，能够不配置该参数。

-Xms：表示 Java 初始化堆的大小，-Xms 与-Xmx 设成同样的值，避免 JVM 反复从新申请内存，致使性能大起大落，默认值为物理内存的 1/64，默认（MinHeapFreeRatio参数能够调整）空余堆内存小于 40% 时，JVM 就会增大堆直到 -Xmx 的最大限制。

-Xmx：表示最大 Java 堆大小，当应用程序须要的内存超出堆的最大值时虚拟机就会提示内存溢出，而且致使应用服务崩溃，所以通常建议堆的最大值设置为可用内存的最大值的80%。如何知道个人 JVM 可以使用最大值，使用 java -Xmx512M -version 命令来进行测试，而后逐渐的增大 512 的值,若是执行正常就表示指定的内存大小可用，不然会打印错误信息，默认值为物理内存的 1/4，默认（MinHeapFreeRatio参数能够调整）空余堆内存大于 70% 时，JVM 会减小堆直到-Xms 的最小限制。

-Xss：表示每一个 Java 线程堆栈大小，JDK 5.0 之后每一个线程堆栈大小为 1M，之前每一个线程堆栈大小为 256K。根据应用的线程所需内存大小进行调整，在相同物理内存下，减少这个值能生成更多的线程，可是操做系统对一个进程内的线程数仍是有限制的，不能无限生成，经验值在 3000~5000 左右。通常小的应用， 若是栈不是很深， 应该是128k 够用的，大的应用建议使用 256k 或 512K，通常不易设置超过 1M，要否则容易出现out ofmemory。这个选项对性能影响比较大，须要严格的测试。

-XX:NewSize：设置新生代内存大小。

-XX:MaxNewSize：设置最大新生代新生代内存大小

-XX:PermSize：设置持久代内存大小

-XX:MaxPermSize：设置最大值持久代内存大小，永久代不属于堆内存，堆内存只包含新生代和老年代。

-XX:+AggressiveOpts：做用如其名（aggressive），启用这个参数，则每当 JDK 版本升级时，你的 JVM 都会使用最新加入的优化技术（若是有的话）。

-XX:+UseBiasedLocking：启用一个优化了的线程锁，咱们知道在咱们的appserver，每一个http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。

-XX:+DisableExplicitGC：在 程序代码中不容许有显示的调用“System.gc()”。每次在到操做结束时手动调用 System.gc() 一下，付出的代价就是系统响应时间严重下降，就和关于 Xms，Xmx 里的解释的原理同样，这样去调用 GC 致使系统的 JVM 大起大落。

-XX:+UseConcMarkSweepGC：设置年老代为并发收集，即 CMS gc，这一特性只有 jdk1.5
后续版本才具备的功能，它使用的是 gc 估算触发和 heap 占用触发。咱们知道频频繁的 GC 会造面 JVM
的大起大落从而影响到系统的效率，所以使用了 CMS GC 后能够在 GC 次数增多的状况下，每次 GC 的响应时间却很短，好比说使用了 CMS
GC 后通过 jprofiler 的观察，GC 被触发次数很是多，而每次 GC 耗时仅为几毫秒。

-XX:+UseParNewGC：对新生代采用多线程并行回收，这样收得快，注意最新的 JVM 版本，当使用 -XX:+UseConcMarkSweepGC 时，-XX:UseParNewGC 会自动开启。所以，若是年轻代的并行 GC 不想开启，能够经过设置 -XX：-UseParNewGC 来关掉。

-XX:MaxTenuringThreshold：设置垃圾最大年龄。若是设置为0的话，则新生代对象不通过 Survivor 区，直接进入老年代。对于老年代比较多的应用（须要大量常驻内存的应用），能够提升效率。若是将此值设置为一 个较大值，则新生代对象会在 Survivor 区进行屡次复制，这样能够增长对象在新生代的存活时间，增长在新生代即被回收的几率，减小Full GC的频率，这样作能够在某种程度上提升服务稳定性。该参数只有在串行 GC 时才有效，这个值的设置是根据本地的 jprofiler 监控后获得的一个理想的值，不能一律而论原搬照抄。

-XX:+CMSParallelRemarkEnabled：在使用 UseParNewGC 的状况下，尽可能减小 mark 的时间。

-XX:+UseCMSCompactAtFullCollection：在使用 concurrent gc 的状况下，防止 memoryfragmention，对 live object 进行整理，使 memory 碎片减小。

-XX:LargePageSizeInBytes：指定 Java heap 的分页页面大小，内存页的大小不可设置过大， 会影响 Perm 的大小。

-XX:+UseFastAccessorMethods：使用 get，set 方法转成本地代码，原始类型的快速优化。

-XX:+UseCMSInitiatingOccupancyOnly：只有在 oldgeneration 在使用了初始化的比例后 concurrent collector 启动收集。

-Duser.timezone=Asia/Shanghai：设置用户所在时区。

-Djava.awt.headless=true：这个参数通常咱们都是放在最后使用的，这全参数的做用是这样的，有时咱们会在咱们的 J2EE 工程中使用一些图表工具如：jfreechart，用于在 web 网页输出 GIF/JPG 等流，在 winodws 环境下，通常咱们的 app server 在输出图形时不会碰到什么问题，可是在linux/unix 环境下常常会碰到一个 exception 致使你在 winodws 开发环境下图片显示的好好但是在 linux/unix 下却显示不出来，所以加上这个参数以避免避这样的状况出现。

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与 jmap -heap 中显示的 New gen 是不一样的。整个堆大小 = 新生代大小 + 老生代大小 + 永久代大小。在保证堆大小不变的状况下，增大新生代后，将会减少老生代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的 3/8。

-XX:CMSInitiatingOccupancyFraction：当堆满以后，并行收集器便开始进行垃圾收集，例如，当没有足够的空间来容纳新分配或提高的对象。对于 CMS 收集器，长时间等待是不可取的，由于在并发垃圾收集期间应用持续在运行（而且分配对象）。所以，为了在应用程序使用完内存以前完成垃圾收集周期，CMS 收集器要比并行收集器更先启动。由于不一样的应用会有不一样对象分配模式，JVM 会收集实际的对象分配（和释放）的运行时数据，而且分析这些数据，来决定何时启动一次 CMS 垃圾收集周期。这个参数设置有很大技巧，基本上知足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100 >= Xmn 就不会出现 promotion failed。例如在应用中 Xmx 是6000，Xmn 是 512，那么 Xmx-Xmn 是 5488M，也就是老年代有 5488M，CMSInitiatingOccupancyFraction=90 说明老年代到 90% 满的时候开始执行对老年代的并发垃圾回收（CMS），这时还 剩 10% 的空间是 5488*10% = 548M，因此即便 Xmn（也就是新生代共512M）里全部对象都搬到老年代里，548M 的空间也足够了，因此只要知足上面的公式，就不会出现垃圾回收时的 promotion failed，所以这个参数的设置必须与 Xmn 关联在一块儿。

-XX:+CMSIncrementalMode：该标志将开启 CMS 收集器的增量模式。增量模式常常暂停 CMS 过程，以便对应用程序线程做出彻底的让步。所以，收集器将花更长的时间完成整个收集周期。所以，只有经过测试后发现正常 CMS 周期对应用程序线程干扰太大时，才应该使用增量模式。因为现代服务器有足够的处理器来适应并发的垃圾收集，因此这种状况发生得不多，用于但 CPU状况。

-XX:NewRatio：年轻代（包括 Eden 和两个 Survivor 区）与年老代的比值（除去持久代），-XX:NewRatio=4 表示年轻代与年老代所占比值为 1:4，年轻代占整个堆栈的 1/5，Xms=Xmx 而且设置了 Xmn 的状况下，该参数不须要进行设置。

-XX:SurvivorRatio：Eden 区与 Survivor 区的大小比值，设置为 8，表示 2 个 Survivor 区（JVM 堆内存年轻代中默认有 2 个大小相等的 Survivor 区）与 1 个 Eden 区的比值为 2:8，即 1 个 Survivor 区占整个年轻代大小的 1/10。

-XX:+UseSerialGC：设置串行收集器。

-XX:+UseParallelGC：设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。

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

-XX:ConcGCThreads：早期 JVM 版本也叫-XX:ParallelCMSThreads，定义并发 CMS 过程运行时的线程数。好比 value=4 意味着 CMS 周期的全部阶段都以 4 个线程来执行。尽管更多的线程会加快并发 CMS 过程，但其也会带来额外的同步开销。所以，对于特定的应用程序，应该经过测试来判断增长 CMS 线程数是否真的可以带来性能的提高。若是还标志未设置，JVM 会根据并行收集器中的 -XX:ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。

-XX:ParallelGCThreads：配置并行收集器的线程数，即：同时有多少个线程一块儿进行垃圾回收，此值建议配置与 CPU 数目相等。

-XX:OldSize：设置 JVM 启动分配的老年代内存大小，相似于新生代内存的初始大小 -XX:NewSize。

以上就是一些经常使用的配置参数，有些参数是能够被替代的，配置思路须要考虑的是 Java 提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度和应用有关，应该经过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么彻底垃圾收集就会很慢，可是频度会下降。假如您把堆的大小和内存的须要一致，彻底收集就很快，可是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为确保最好的性能，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程当中出现。

假如系统花费不少的时间收集垃圾，请减少堆大小。一次彻底的垃圾收集应该不超过 3-5 秒。假如垃圾收集成为瓶颈，那么须要指定代的大小，检查垃圾收集的周详输出，研究垃圾收集参数对性能的影响。当增长处理器时，记得增长内存，由于分配可以并行进行，而垃圾收集不是并行的。

三、设置系统属性

以前说过，Tomcat 的语言编码，配置起来很慢，要通过屡次设置才能够了，不然中文颇有可能出现乱码状况。譬如汉字“中”，以 UTF-8 编码后获得的是 3 字节的值 %E4%B8%AD，而后经过 GET 或者 POST 方式把这 3 个字节提交到 Tomcat 容器，若是你不告诉 Tomcat 个人参数是用 UTF-8编码的，那么 Tomcat 就认为你是用 ISO-8859-1 来编码的，而 ISO8859-1（兼容 URI 中的标准字符集 US-ASCII）是兼容 ASCII 的单字节编码而且使用了单字节内的全部空间，所以 Tomcat 就觉得你传递的用 ISO-8859-1 字符集编码过的 3 个字符，而后它就用 ISO-8859-1 来解码。

设置起来不难使用“ -D<名称>=<值> ”来设置系统属性：

-Djavax.servlet.request.encoding=UTF-8

-Djavax.servlet.response.encoding=UTF-8 

-Dfile.encoding=UTF-8 

-Duser.country=CN 

-Duser.language=zh

四、常见的 Java 内存溢出有如下三种

（1） java.lang.OutOfMemoryError: java heap space —-JVM Heap（堆）溢出

JVM 在启动的时候会自动设置 JVM Heap 的值，其初始空间（即-Xms）是物理内存的1/64，最大空间（-Xmx）不可超过物理内存。能够利用 JVM提供的 -Xmn -Xms -Xmx 等选项可进行设置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM 中若是 98％ 的时间是用于 GC，且可用的 Heap size 不足 2％ 的时候将抛出此异常信息。

解决方法：手动设置 JVM Heap（堆）的大小。  
（2） java.lang.OutOfMemoryError: PermGen space  —- PermGen space溢出。

PermGen space 的全称是 Permanent Generation space，是指内存的永久保存区域。为何会内存溢出，这是因为这块内存主要是被 JVM 存放Class 和 Meta 信息的，Class 在被 Load 的时候被放入 PermGen space 区域，它和存放 Instance 的 Heap 区域不一样，sun 的 GC 不会在主程序运行期对 PermGen space 进行清理，因此若是你的 APP 会载入不少 CLASS 的话，就极可能出现 PermGen space 溢出。

解决方法： 手动设置 MaxPermSize 大小

（3） java.lang.StackOverflowError   —- 栈溢出

栈溢出了，JVM 依然是采用栈式的虚拟机，这个和 C 与 Pascal 都是同样的。函数的调用过程都体如今堆栈和退栈上了。调用构造函数的 “层”太多了，以至于把栈区溢出了。一般来说，通常栈区远远小于堆区的，由于函数调用过程每每不会多于上千层，而即使每一个函数调用须要 1K 的空间（这个大约至关于在一个 C 函数内声明了 256 个 int 类型的变量），那么栈区也不过是须要 1MB 的空间。一般栈的大小是 1－2MB 的。
一般递归也不要递归的层次过多，很容易溢出。

解决方法：修改程序。

更多信息，请参考如下文章：

JVM 垃圾回收调优总结

http://developer.51cto.com/art/201201/312639.htm

JVM调优总结：典型配置举例

http://developer.51cto.com/art/201201/311739.htm

JVM基础：JVM参数设置、分析 

http://developer.51cto.com/art/201201/312018.htm

JVM 堆内存相关的启动参数：年轻代、老年代和永久代的内存分配

http://www.2cto.com/kf/201409/334840.html

Java 虚拟机–新生代与老年代GC

http://my.oschina.net/sunnywu/blog/332870

JVM（Java虚拟机）优化大全和案例实战

http://blog.csdn.net/kthq/article/details/8618052

JVM内存区域划分Eden Space、Survivor Space、Tenured Gen，Perm Gen解释 

http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=29632145&id=4616836

 

 

 

原文：http://blog.chopmoon.com/favorites/231.html