JVM调优常用参数配置

说明：

1、一般初始堆和最大堆设置一样，因为：现在内存不是什么稀缺的资源，但是如果不一样，从初始堆到最大堆的过程会有一定的性能开销，所以一般设置为初始堆和最大堆一样。64位系统理论上可以设置为无限大，但是一般设置为 4G ,因为如果再大，JVM进行垃圾回收出现的暂停时间会比较长，这样全GC过长，影响JVM对外提供服务，所以不能太大。一般设置为4G。

2、-XX:NewRaio和-XX:SurvivorRatio这两个参数，都是设置年轻代和年老代的大小的，设置一个即可，第一是设置年轻代的大小，第二个是设置比值，理论上设置一个既可以满足需求

打印GC回收的过程日志信息

以下配置主要针对分代收集回收算法而言

年轻代的设置很关键

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

典型设置：

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

吞吐量优先的并行收集器

并行收集器主要以到达一定的吞吐量为目标，适用于后台处理

响应时间优先的并发收集器

并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

6.1年轻代大小选择

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

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

6.2年老代大小选择

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

1、并发垃圾收集信息

2、持久代并发收集次数

3、传统GC信息

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

6.3吞吐量优先的应用

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

6.4较小堆引起的碎片问题

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

Jconsole,jProfile,VisualVM

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

JProfiler：商业软件，需要付费，但是功能强大

VisualVM:JDK自带，功能强大，与Jprofiler类似，推荐

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

上面这些调优工具都提供了强大的功能，但是总的来说一般分为以下几类功能：

一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（ 常见的集合对象引用 ）分析，基本都可以找到泄漏点。

持久代沾满处理：

1、-XX:MaxPermSize=16m

2、换JDK比如：JRocket

系统内存被沾满：

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

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

java程序内存问题的诊断方法：

查看jmap的命令参数，帮助查看堆信息

-Xss ：线程栈空间

-Xms : 初始堆空间，如： -Xms512M

-Xmx : 最大堆空间，如： -Xmx512M

-XX:MinHeapFreeRatio : 堆空间最小空闲比，当堆空间空闲内存小于这个数值时，JVM会扩展堆空间。

-XX:MaxHeapFreeRatio : 堆空间最大空闲比，当堆空间空闲内存大于这个数值时，JVM会压缩堆空间，得到一个较小的堆。

-XX:NewSize : 新生代初始空间

-XX:MaxNewSize : 最大新生代空间

-Xmn : 相当于设置相同的 -XX:NewSize 和 -XX:MaxNewSize .

-XX:SurvivorRatio : 新生代中eden空间和s0空间的比例

-XX:TargetSurvivorRatio : survivor区的可使用率，当survivor区的空间使用率达到这个数值时，会将对象送入老年代。

-XX:NewRatio : 老年代 / 新生代的空间比例

-XX:MetaspaceSize=512m : 分配给类元数据空间的初始大小，以bytes为单位，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当的降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize（如果设置了的话），适当的提高该值。

-XX:MaxMetaspaceSize=512m : 分配给类元数据空间的最大值, 超过此值就会触发Full GC. 此值仅受限于系统内存的大小, JVM会动态地改变此值

-XX:MinMetaspaceFreeRatio ,在GC之后，最小的Metaspace剩余空间容量的百分比，减少为class metadata分配空间导致的垃圾收集。

-XX:MaxMetaspaceFreeRatio ,在GC之后，最大的Metaspace剩余空间容量的百分比，减少为class metadata释放空间导致的垃圾收集。

-XX:CompressedClassSpaceSize=512m : 类指针压缩空间大小, 默认为1G

-XX:+PrintGCDetails : 打印GC细节

-XX:+PrintGC :

-XX:+PrintGCTimeStamps :

-XX:+PrintHeapAtGC :

Java 8 以前的JVM内存结构图：

其中：

虚拟机栈 在运行时使用 栈帧 保存上下文，栈帧中存储了以下内容：

更为精细地， 堆 和 方法区 的结构如下：

堆 分为 新生代 和 老年代 .

新生代 分为 Eden区 、 s0区（survivor space0或from space） 和 s1区（survivor space1或to space） 。

大部分新创建的对象进入Eden区，幸存区s0区和s1区存放经历了至少一次GC的“幸存者”。如果幸存区中的对象到了指定年龄仍未被回收，则有机会进入 老年代（tenured）

对于习惯了HotSpot虚拟机的程序员来说，很多都愿意将 方法区 称作 永久代 。本质上来讲两者并不等价，仅因为Hotspot将GC分代扩展至方法区，或者说使用永久代来实现方法区。在其他虚拟机上是没有永久代的概念的。也就是说方法区是Java虚拟机规范，永久代是Hotspot针对该规范进行的实现。

堆 和 方法区 都是被JVM中所有线程共享的。

Java 8以后的JVM内存结构图：

Java8中，Hotspot取消了永久代，永久代的参数 -XX:PermSize 和 -XX：MaxPermSize 也随之失效。

对于Java8，HotSpots取消了永久代，是不是就没有方法区了呢？当然不是，方法区只是一个规范，只不过它的实现变了。

在Java8中， 方法区存在于元空间(Metaspace) 。同时，元空间不再与堆连续，而且是存在于本地内存（Native memory）。

本地内存（Native memory） ，也称为 C-Heap ，是供JVM自身进程使用的。当Java Heap空间不足时会触发GC，但本地内存空间不够却不会触发GC。

元空间存在于本地内存，意味着只要本地内存足够，它不会出现像永久代中 java.lang.OutOfMemoryError: PermGen space 这种错误。默认情况下元空间是可以无限使用本地内存的，但JVM同样提供了参数 -XX:MaxMetaspaceSize 来限制它使用的空间。

---