本文目录一览：
- 1、6个重要的JVM性能参数
- 2、如何设置JVM参数
- 3、JVM常用参数
- 4、使用jstat需要在jvm中配置添加什么参数
- 5、JVM环境参数怎么配置？
- 6、JVM内存设置多大合适？Xmx和Xmn如何设置？
6个重要的JVM性能参数
围绕垃圾收集和内存，您可以将600多个参数传递给 JVM 。如果包括其他方面，则JVM参数总数将很容易超过1000+。任何人都无法消化和理解太多的论据。在本文中，重点介绍了七个重要的 JVM 参数，在 Java性能测试 中起着非常重要的作用。
-Xmx 可能是最重要的 JVM 参数。 -Xmx 定义要分配给应用程序的最大堆大小。。您可以这样定义应用程序的堆大小： -Xmx2g 。
堆大小在影响应用性能和所需物理硬件需求。这带来了一个问题，我的应用程序正确的堆大小是多少？我应该为应用程序分配大堆大小还是小堆大小？答案是：取决于需求和预算。
将 -Xms 和 -Xmx 设置为相同值的会提高JVM性能
元空间是将存储 JVM 的元数据定义（例如类定义，方法定义）的区域。默认情况下，可用于存储此元数据信息的内存量是无限的（即受您的容器或计算机的RAM大小的限制）。您需要使用 -XX：MaxMetaspaceSize 参数来指定可用于存储元数据信息的内存量的上限。
-XX:MaxMetaspaceSize=256m
OpenJDK中有7种不同的GC算法：
如果您未明确指定GC算法，那么JVM将选择默认算法。在Java 8之前， Parallel GC 是默认的GC算法。从Java 9开始， G1 GC 是默认的GC算法。
GC算法的选择对于确定应用程序的性能起着至关重要的作用。根据我们的研究，我们正在使用Z GC算法观察到出色的性能结果。如果使用 JVM 11+ ，则可以考虑使用 Z GC 算法（即 -XX：+ UseZGC ）。
下表总结了激活每种垃圾收集算法所需传递的JVM参数。
垃圾收集日志包含有关垃圾收集事件，回收的内存，暂停时间段等信息，可以通过传递以下JVM参数来启用垃圾收集日志：
从JDK 1到JDK 8：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{file-path}
从JDK 9及更高版本开始：
-Xlog:gc*:file={file-path}
Demo：
通常，GC日志用于调整垃圾回收性能。但是，GC日志包含重要的微观指标。这些指标可用于预测应用程序的可用性和性能特征。在本文中将重点介绍一种这样的标尺：GC吞吐量。GC吞吐量是您的应用程序在处理客户交易中花费的时间与它在处理GC活动中花费的时间之比。假设您的应用程序的GC吞吐量为98％，则意味着应用程序将其98％的时间用于处理客户活动，其余2％用于GC活动。
现在，让我们看一个健康的JVM的堆使用情况图：
您会看到一个完美的锯齿图案。您会注意到，当运行Full GC（红色三角形）时，内存利用率将一直下降到最低。
现在，让我们看一下有问题的JVM的堆使用情况图：
您可以注意到，在图表的右端，即使GC反复运行，内存利用率也没有下降。这是一个典型的内存泄漏迹象，表明该应用程序正在存在某种内存问题。
如果您仔细观察一下该图，您会发现重复的完整GC开始在上午8点左右开始。但是，该应用程序仅在上午8:45左右开始获取OutOfMemoryError。到上午8点，该应用程序的GC吞吐量约为99％。但是，在上午8点之后，GC吞吐量开始下降到60％。因为当重复的GC运行时，该应用程序将不会处理任何客户交易，而只会进行GC活动。
OutOfMemoryError 是一个严重的问题，它将影响您的应用程序的可用性和性能。要诊断 OutOfMemoryError 或任何与内存相关的问题，必须在应用程序开始遇到 OutOfMemoryError 的那一刻或一瞬间捕获堆转储。由于我们不知道何时会抛出 OutOfMemoryError ，因此很难在抛出时左右的正确时间手动捕获堆转储。但是，可以通过传递以下JVM参数来自动化捕获堆转储：
-XX：+ HeapDumpOnOutOfMemoryError和-XX：HeapDumpPath = {HEAP-DUMP-FILE-PATH}
在 -XX：HeapDumpPath 中，需要指定堆转储所在的文件路径。传递这两个JVM参数时，将在抛出 OutOfMemoryError 时自动捕获堆转储并将其写入定义的文件路径。例：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof
一旦捕获了堆转储，就可以使用 HeapHero 和 EclipseMAT 之类的工具来分析堆转储。
每个应用程序将具有数十，数百，数千个线程。每个线程都有自己的堆栈。在每个线程的堆栈中，存储以下信息：
他们每个都消耗内存。如果它们的使用量超出某个限制，则会引发 StackOverflowError 。可以通过传递-Xss参数来增加线程的堆栈大小限制。例：
-Xss256k
如果将此 -Xss 值设置为一个很大的数字，则内存将被阻塞并浪费。假设您将 -Xss 值指定为 2mb ，而只需要 256kb ，那么您将浪费大量的内存。
假设您的应用程序有500个进程，然后 -Xss 值为 2Mb ，则您的线程将消耗 1000Mb 的内存。另一方面，如果您仅将 -Xss 分配为 256kb ，那么您的线程将仅消耗 125Mb 的内存。每个JVM将节省 875Mb 内存。
注意：线程是在堆（即 -Xmx ）之外创建的，因此这 1000Mb 将是您已经分配的-Xmx值的补充。
现代应用程序使用多种协议（即SOAP，REST，HTTP，HTTPS，JDBC，RMI）与远程应用程序连接。有时远程应用程序可能需要很长时间才能做出响应，有时它可能根本不响应。
如果没有正确的超时设置，并且远程应用程序的响应速度不够快，则您的应用程序线程/资源将被卡住。远程应用程序无响应可能会影响您的应用程序的可用性。它可以使您的应用程序停止磨削。为了保护应用程序的高可用性，应配置适当的超时设置。
您可以在JVM级别传递这两个强大的超时网络属性，这些属性可以全局适用于所有使用 java.net.URLConnection 的协议处理程序：
sun.net.client.defaultConnectTimeout ：指定建立到主机的连接的超时（以毫秒为单位）。例如，对于HTTP连接，它是与HTTP服务器建立连接时的超时。当建立与资源的连接时， sun.net.client.defaultReadTimeout 指定从输入流读取时的超时（以毫秒为单位）。
例如，如果您要将这些属性设置为2秒：
注意，默认情况下，这两个属性的值为-1，这表示未设置超时。
如何设置JVM参数
设置eclipse jvm参数
打开Eclipse 或者 MyEclipse
打开 Windows - Preferences - Java - Installed JREs
选中你所使用的 JDK，然后点击 Edit，会出现如下图：
在 Default VM Arguments输入框内输入： -Xms512m -Xmx512m
解释：
-Xms是设置java虚拟机的最小分配内存；-Xmx则是最大分配内存；512m为内存空间
一般-Xmx设置为你电脑物理内存的1/4，而把-Xms和 -Xmx设置为一样，
其实你可以设置得更大一些，只要系统能分配足够的内存就可以了，如果设置过大系统会提示你的。
JVM常用参数
-Xmx4g 初始堆大小 4g
-Xms4g 最大堆大小4g
-Xmn512m 年轻代大小(1.4or lator)整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8
-XX:MetaspaceSize=256m 设置元空间初始大小为256m
-XX:MaxMetaspaceSize=512m 设置元空间最大可分配大小512m
-Xss256k 每个线程的堆栈大小256k
-XX:+ExplicitGCInvokesConcurrent 降低每次Full GC的时间，其实就是启用多线程去执行
-XX:+UseConcMarkSweepGC 启用CMS做为垃圾收集
-XX:+UseCMSInitiatingOccupancyOnly 只有开启了这个参数，CMSInitiatingOccupancyFraction这个参数才会生效
-XX:CMSInitiatingOccupancyFraction=70 CMS垃圾收集器，当老年代达到70%时，触发CMS垃圾回收。
-XX:ParallelGCThreads=4 选项指定在默认垃圾收集器的并行操作期间使用的线程数为4
-XX:-UseBiasedLocking 关闭用户偏向锁
-XX:AutoBoxCacheMax=20000 参数是设置Integer缓存上限的参数,在VM初始化期间java.lang.Integer.IntegerCache.high属性可以被设置和保存在私有的系统属性sun.misc.VM class中。理论上讲，当系统需要频繁使用Integer时，或者说堆内存中存在大量的Integer对象时，可以考虑提高Integer缓存上限，避免JVM重复创造对象，提高内存的使用率，减少GC的频率，从而提高系统的性能。
-XX:MaxTenuringThreshold=6 设置的是年龄阈值，默认15（对象被复制的次数），这里设置成了6次
-XX:+PrintGCApplicationStoppedTime 打印垃圾收集时 , 系统的停顿时间
-XX:+PrintGCDateStamps 打印CG发生的时间戳
-XX:+PrintGCDetails 来打印详细的GC日志来查看
-XX:+PrintCodeCache 会打印Code Cache区的使用情况。
-Xloggc:/dev/shm/gc.log 指定gc的log日志所在位置/dev/shm/gc.log
-XX:+UseGCLogFileRotation 打开或关闭GC日志滚动记录功能，要求必须设置 -Xloggc参数
-XX:NumberOfGCLogFiles=2 设置滚动日志文件的个数，必须大于1
日志文件命名策略是，filename.0, filename.1, ..., filename.n-1，其中n是该参数的值
-XX:GCLogFileSize=10m 设置滚动日志文件的大小，必须大于8k
当前写日志文件大小超过该参数值时，日志将写入下一个文件
-XX:+HeapDumpOnOutOfMemoryError 表示当JVM发生OOM时，自动生成DUMP文件。
-XX:HeapDumpPath=/root/logs/ 发生了 内存溢出错误 dump路径为root/logs/ （一般与HeapDumpOnOutOfMemoryError参数一块使用）
使用jstat需要在jvm中配置添加什么参数
典型JVM参数设置： java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -Xmx3550m：设置JVM最大可用内存为3550M。 -Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。使用jstat需要在jvm中配置添加什么参数
JVM环境参数怎么配置？
典型JVM参数设置：
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内存设置多大合适？Xmx和Xmn如何设置？
问题:
新上线一个java服务，或者是RPC或者是WEB站点， 内存的设置该怎么设置呢？设置成多大比较合适，既不浪费内存，又不影响性能呢？
分析：
依据的原则是根据Java Performance里面的推荐公式来进行设置。
具体来讲：
Java整个堆大小设置，Xmx 和 Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍
永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍。
年轻代Xmn的设置为老年代存活对象的1-1.5倍。
老年代的内存大小设置为老年代存活对象的2-3倍。
BTW：
1、Sun官方建议年轻代的大小为整个堆的3/8左右， 所以按照上述设置的方式，基本符合Sun的建议。
2、堆大小=年轻代大小+年老代大小， 即xmx=xmn+老年代大小 。 Permsize不影响堆大小。
3、为什么要按照上面的来进行设置呢？ 没有具体的说明，但应该是根据多种调优之后得出的一个结论。
如何确认老年代存活对象大小？
方式1（推荐/比较稳妥）：
JVM参数中添加GC日志，GC日志中会记录每次FullGC之后各代的内存大小，观察老年代GC之后的空间大小。可观察一段时间内（比如2天）的FullGC之后的内存情况，根据多次的FullGC之后的老年代的空间大小数据来预估FullGC之后老年代的存活对象大小（可根据多次FullGC之后的内存大小取平均值）
方式2：（强制触发FullGC, 会影响线上服务，慎用）
方式1的方式比较可行，但需要更改JVM参数，并分析日志。同时，在使用CMS回收器的时候，有可能不能触发FullGC（只发生CMS GC），所以日志中并没有记录FullGC的日志。在分析的时候就比较难处理。
BTW：使用jstat -gcutil工具来看FullGC的时候， CMS GC是会造成2次的FullGC次数增加。 具体可参见之前写的一篇关于jstat使用的文章
所以，有时候需要强制触发一次FullGC，来观察FullGC之后的老年代存活对象大小。
注：强制触发FullGC，会造成线上服务停顿（STW），要谨慎，建议的操作方式为，在强制FullGC前先把服务节点摘除，FullGC之后再将服务挂回可用节点，对外提供服务
在不同时间段触发FullGC，根据多次FullGC之后的老年代内存情况来预估FullGC之后的老年代存活对象大小
如何触发FullGC ？
使用jmap工具可触发FullGC
jmap -dump:live,format=b,file=heap.bin pid 将当前的存活对象dump到文件，此时会触发FullGC
jmap -histo:live pid 打印每个class的实例数目,内存占用,类全名信息.live子参数加上后,只统计活的对象数量. 此时会触发FullGC
具体操作实例：
以我司的一个RPC服务为例。
BTW：刚上线的新服务，不知道该设置多大的内存的时候，可以先多设置一点内存，然后根据GC之后的情况来进行分析。
初始JVM内存参数设置为： Xmx=2G Xms=2G xmn=1G
使用jstat 查看当前的GC情况。如下图：
YGC平均耗时： 173.825s/15799=11ms
FGC平均耗时：0.817s/41=19.9ms
平均大约10-20s会产生一次YGC
看起来似乎不错，YGC触发的频率不高，FGC的耗时也不高，但这样的内存设置是不是有些浪费呢？
为了快速看数据，我们使用了方式2，产生了几次FullGC，FullGC之后，使用的jmap -heap 来看的当前的堆内存情况（也可以根据GC日志来看）
heap情况如下图：（命令 ： jmap -heap pid）
上图中的concurrent mark-sweep generation即为老年代的内存描述。
老年代的内存占用为100M左右。 按照整个堆大小是老年代（FullGC）之后的3-4倍计算的话，设置各代的内存情况如下：
Xmx=512m Xms=512m Xmn=128m PermSize=128m 老年代的大小为 （512-128=384m）为老年代存活对象大小的3倍左右
调整之后的，heap情况
GC情况如下：
YGC 差不多在10s左右触发一次。每次YGC平均耗时大约9.41ms。可接受。
FGC平均耗时：0.016s/2=8ms
整体的GC耗时减少。但GC频率比之前的2G时的要多了一些。
注： 看上述GC的时候，发现YGC的次数突然会增多很多个，比如 从1359次到了1364次。具体原因是？
总结：
在内存相对紧张的情况下，可以按照上述的方式来进行内存的调优， 找到一个在GC频率和GC耗时上都可接受的一个内存设置，可以用较小的内存满足当前的服务需要
但当内存相对宽裕的时候，可以相对给服务多增加一点内存，可以减少GC的频率，GC的耗时相应会增加一些。 一般要求低延时的可以考虑多设置一点内存， 对延时要求不高的，可以按照上述方式设置较小内存。
补充：
永久代（方法区）并不在堆内，所以之前有看过一篇文章中描述的 整个堆大小=年轻代+年老代+永久代的描述是不正确的。
转自:
-verbose:gc 现实垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一
-XX:SurvivorRatio=2 :生还者池的大小,默认是2，如果垃圾回收变成了瓶颈，您可以尝试定制生成池设置
-XX:NewSize: 新生成的池的初始大小。 缺省值为2M。
-XX:MaxNewSize: 新生成的池的最大大小。 缺省值为32M。
+XX:AggressiveHeap 会使得 Xms没有意义。这个参数让jvm忽略Xmx参数,疯狂地吃完一个G物理内存,再吃尽一个G的swap。
-Xss：每个线程的Stack大小，“-Xss 15120” 这使得JBoss每增加一个线程（thread)就会立即消耗15M内存，而最佳值应该是128K,默认值好像是512k.