四、JVM性能调优

最新推荐文章于 2024-08-16 17:26:15 发布

仰望星空的尘埃

最新推荐文章于 2024-08-16 17:26:15 发布

阅读量649

点赞数

分类专栏： JAVA技术文章标签： JAVA性能调优 JVM调优工具 JVM优化 JVM垃圾回收策略调优

本文链接：https://blog.csdn.net/u010285974/article/details/79600488

版权

JAVA技术专栏收录该内容

162 篇文章 3 订阅

订阅专栏

一、性能调优

1.内存分配调优

在JVM启动参数中，可以设置跟内存、垃圾回收相关的一些参数设置，默认情况不做任何设置JVM会工作的很好，但对一些配置很好的Server和具体的应用必须仔细调优才能获得最佳性能。通过设置我们希望达到一些目标：

GC的时间足够的小
GC的次数足够的少
发生Full GC的周期足够的长

前两个目前是相悖的，要想GC时间小必须要一个更小的堆，要保证GC次数足够少，必须保证一个更大的堆，我们只能取其平衡。

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

(2)年轻代和年老代将根据默认的比例（1：2）分配堆内存，可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代，比如年轻代，通过 -XX:newSize -XX:MaxNewSize来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小;

(3)年轻代和年老代设置多大才算合理？这个我问题毫无疑问是没有答案的，否则也就不会有调优。我们观察一下二者大小变化有哪些影响

更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC
更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次的GC时间会更短；大的年老代会减少Full GC的频率
如何选择应该依赖应用程序对象生命周期的分布情况：如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大。但很多应用都没有这样明显的特性，在抉择时应该根据以下两点：（A）本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理（B）通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响Full GC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间

(4)线程堆栈的设置：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

另外，通过-XX:MaxTenuringThreshold=n来控制新生代存活时间，尽量让对象在新生代被回收

2.GC策略调优

使用SerialGC的场景：
1、如果应用的堆大小在100MB以内。
2、如果应用在一个单核单线程的服务器上面，并且对应用暂停的时间无需求。

使用ParallelGC的场景:
如果需要应用在高峰期有较好的性能，但是对应用停顿时间无高要求（比如：停顿1s甚至更长）。

使用G1、CMS场景:
1、对应用的延迟有很高的要求。
2、如果内存大于6G请使用G1。

二、调优工具

1.JDK自带监控、分析JVM性能的工具

JConsole，JVisualvm

2.JDK自带监控、分析JVM性能的命令

名称	作用
jps	JVM Process Status Tool，显示指定系统内所有的HotSpot虚拟机进程
jstat	JVM Statistics Monitoring Tool，用于收集Hotspot虚拟机各个方面的运行参数
jinfo	Configuration Info for Java，显示虚拟机配置信息
jmap	Memory map for java，生成虚拟机的内存转储快照
jhat	JVM heap Dunp Browser，用于分析heapdump文件，他会建立一个HTTP/HTML服务，让用户可通过浏览器查看
jstack	Stack Track for java ，显示虚拟机线程快照

A、 jps(Java Virtual Machine Process Status Tool)

jps主要用来输出JVM中运行的进程状态信息。语法格式如下：

1	`jps [options] [hostid]`

如果不指定hostid就默认为当前主机或服务器。

命令行参数选项说明如下：

-q 不输出类名、Jar名和传入main方法的参数

-m 输出传入main方法的参数

-l 输出main类或Jar的全限名

- v 输出传入JVM的参数

比如下面：

root@ubuntu:/ # jps -m -l

2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2 .2.5 /etc/jetty .xml

29920 com.sun.tools.hat.Main -port 9998 /tmp/dump .dat

3149 org.apache.catalina.startup.Bootstrap start

30972 sun.tools.jps.Jps -m -l

8247 org.apache.catalina.startup.Bootstrap start

25687 com.sun.tools.hat.Main -port 9999 dump.dat

21711 mrf-center.jar

B、 jstack

jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：

jstack [option] pid

jstack [option] executable core

jstack [option] [server- id @]remote- hostname -or-ip

命令行参数选项说明如下：

1 2	`-l long listings，会打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况` `-m mixed mode，不仅会输出Java堆栈信息，还会输出C` `/C` `++堆栈信息（比如Native方法）`

jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。下面我们来一个实例找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。

第一步先找出Java进程ID，我部署在服务器上的Java应用名称为mrf-center：

1 2	`root@ubuntu:/` `# ps -ef \| grep mrf-center \| grep -v grep` `root 21711 1 1 14:47 pts` `/3` `00:02:10 java -jar mrf-center.jar`

得到进程ID为21711，第二步找出该进程内最耗费CPU的线程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid，我这里用第三个，输出如下：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用

1	`printf` `"%x\n"` `21742`

得到21742的十六进制值为54ee，下面会用到。

OK，下一步终于轮到jstack上场了，它用来输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：

1 2	`root@ubuntu:/` `# jstack 21711 \| grep 54ee` `"PollIntervalRetrySchedulerThread"` `prio=10 tid=0x00007f950043e000 nid=0x54ee` `in` `Object.wait() [0x00007f94c6eda000]`

可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，我找了下我的代码，定位到下面的代码：

// Idle wait

getLog().info( "Thread [" + getName() + "] is idle waiting..." );

schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;

long now = System.currentTimeMillis();

long waitTime = now + getIdleWaitTime();

long timeUntilContinue = waitTime - now;

synchronized (sigLock) {

try {

if (!halted.get()) {

sigLock.wait(timeUntilContinue);

}

catch (InterruptedException ignore) {

}

它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。

C、 jmap（Memory Map）和jhat（Java Heap Analysis Tool）

jmap用来查看堆内存使用状况，一般结合jhat使用。

jmap语法格式如下：

jmap [option] pid

jmap [option] executable core

jmap [option] [server- id @]remote- hostname -or-ip

如果运行在64位JVM上，可能需要指定-J-d64命令选项参数。

1	`jmap -permstat pid`

打印进程的类加载器和类加载器加载的持久代对象信息，输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如下图：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

使用jmap -heap pid查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况。比如下面的例子：

root@ubuntu:/ # jmap -heap 21711

Attaching to process ID 21711, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 20.10-b01

using thread- local object allocation.

Parallel GC with 4 thread(s)

Heap Configuration:

MinHeapFreeRatio = 40

MaxHeapFreeRatio = 70

MaxHeapSize = 2067791872 (1972.0MB)

NewSize = 1310720 (1.25MB)

MaxNewSize = 17592186044415 MB

OldSize = 5439488 (5.1875MB)

NewRatio = 2

SurvivorRatio = 8

PermSize = 21757952 (20.75MB)

MaxPermSize = 85983232 (82.0MB)

Heap Usage:

PS Young Generation

Eden Space:

capacity = 6422528 (6.125MB)

used = 5445552 (5.1932830810546875MB)

free = 976976 (0.9317169189453125MB)

84.78829520089286% used

From Space:

capacity = 131072 (0.125MB)

used = 98304 (0.09375MB)

free = 32768 (0.03125MB)

75.0% used

To Space:

capacity = 131072 (0.125MB)

used = 0 (0.0MB)

free = 131072 (0.125MB)

0.0% used

PS Old Generation

capacity = 35258368 (33.625MB)

used = 4119544 (3.9287033081054688MB)

free = 31138824 (29.69629669189453MB)

11.683876009235595% used

PS Perm Generation

capacity = 52428800 (50.0MB)

used = 26075168 (24.867218017578125MB)

free = 26353632 (25.132781982421875MB)

49.73443603515625% used

....

使用jmap -histo[:live] pid查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象，如下：

root@ubuntu:/ # jmap -histo:live 21711 | more

num #instances #bytes class name

----------------------------------------------

1: 38445 5597736 <constMethodKlass>

2: 38445 5237288 <methodKlass>

3: 3500 3749504 <constantPoolKlass>

4: 60858 3242600 <symbolKlass>

5: 3500 2715264 <instanceKlassKlass>

6: 2796 2131424 <constantPoolCacheKlass>

7: 5543 1317400 [I

8: 13714 1010768 [C

9: 4752 1003344 [B

10: 1225 639656 <methodDataKlass>

11: 14194 454208 java.lang.String

12: 3809 396136 java.lang.Class

13: 4979 311952 [S

14: 5598 287064 [[I

15: 3028 266464 java.lang.reflect.Method

16: 280 163520 <objArrayKlassKlass>

17: 4355 139360 java.util.HashMap$Entry

18: 1869 138568 [Ljava.util.HashMap$Entry;

19: 2443 97720 java.util.LinkedHashMap$Entry

20: 2072 82880 java.lang.ref.SoftReference

21: 1807 71528 [Ljava.lang.Object;

22: 2206 70592 java.lang.ref.WeakReference

23: 934 52304 java.util.LinkedHashMap

24: 871 48776 java.beans.MethodDescriptor

25: 1442 46144 java.util.concurrent.ConcurrentHashMap$HashEntry

26: 804 38592 java.util.HashMap

27: 948 37920 java.util.concurrent.ConcurrentHashMap$Segment

28: 1621 35696 [Ljava.lang.Class;

29: 1313 34880 [Ljava.lang.String;

30: 1396 33504 java.util.LinkedList$Entry

31: 462 33264 java.lang.reflect.Field

32: 1024 32768 java.util.Hashtable$Entry

33: 948 31440 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;

class name是对象类型，说明如下：

B byte

C char

D double

F float

I int

J long

Z boolean

[ 数组，如[I表示int[]

[L+类名其他对象

还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。jmap进行dump命令格式如下：

1	`jmap -dump:` `format` `=b,` `file` `=dumpFileName`

我一样地对上面进程ID为21711进行Dump：

root@ubuntu:/ # jmap -dump:format=b,file=/tmp/dump.dat 21711

Dumping heap to /tmp/dump .dat ...

Heap dump file created

dump出来的文件可以用MAT、VisualVM等工具查看，这里用jhat查看：

root@ubuntu:/ # jhat -port 9998 /tmp/dump.dat

Reading from /tmp/dump .dat...

Dump file created Tue Jan 28 17:46:14 CST 2014

Snapshot read , resolving...

Resolving 132207 objects...

Chasing references, expect 26 dots..........................

Eliminating duplicate references..........................

Snapshot resolved.

Started HTTP server on port 9998

Server is ready.

然后就可以在浏览器中输入主机地址:9998查看了：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

上面红线框出来的部分大家可以自己去摸索下，最后一项支持OQL（对象查询语言）。

D、jstat（JVM统计监测工具）

语法格式如下：

1	`jstat [ generalOption \| outputOptions vmid [interval[s\|ms] [count]] ]`

vmid是虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为4：

root@ubuntu:/ # jstat -gc 21711 250 4

S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT

192.0  192.0   64.0   0.0    6144.0   1854.9   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   2109.7   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

要明白上面各列的意义，先看JVM堆内存布局：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

可以看出：

1 2	`堆内存 = 年轻代 + 年老代 + 永久代` `年轻代 = Eden区 + 两个Survivor区（From和To）`

现在来解释各列含义：

S0C、S1C、S0U、S1U：Survivor 0 /1 区容量（Capacity）和使用量（Used）

EC、EU：Eden区容量和使用量

OC、OU：年老代容量和使用量

PC、PU：永久代容量和使用量

YGC、YGT：年轻代GC次数和GC耗时

FGC、FGCT：Full GC次数和Full GC耗时

GCT：GC总耗时

E、jinfo（JVM信息）

jinfo可以输出并修改运行时的java 进程的opts（JVM相关运行参数）。用处比较简单，用于输出JAVA系统参数及命令行参数。

命令格式：

jinfo [option] pid

[html] view plain copy

[root@develop117 bin]# ./jinfo 568
Attaching to process ID 568, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.45-b01
Java System Properties:
java.runtime.name = Java(TM) SE Runtime Environment
sun.rmi.transport.tcp.responseTimeout = 3000000
sun.boot.library.path = /usr/local/java/jre/lib/amd64
java.vm.version = 20.45-b01
shared.loader =
java.vm.vendor = Sun Microsystems Inc.
java.vendor.url = http://java.sun.com/
path.separator = :
tomcat.util.buf.StringCache.byte.enabled = true
java.util.logging.config.file = /usr/local/tomcat/flybus/tomcat-flybus-admin/conf/logging.properties
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
file.encoding.pkg = sun.io
sun.java.launcher = SUN_STANDARD
user.country = CN
sun.os.patch.level = unknown
java.vm.specification.name = Java Virtual Machine Specification
user.dir = /root
java.runtime.version = 1.6.0_45-b06
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
java.endorsed.dirs = /usr/local/tomcat/flybus/tomcat-flybus-admin/endorsed
os.arch = amd64
java.io.tmpdir = /usr/local/tomcat/flybus/tomcat-flybus-admin/temp
line.separator =
java.vm.specification.vendor = Sun Microsystems Inc.
java.naming.factory.url.pkgs = org.apache.naming
java.util.logging.manager = org.apache.juli.ClassLoaderLogManager
os.name = Linux
sun.jnu.encoding = UTF-8
java.library.path = /usr/local/java/jre/lib/amd64/server:/usr/local/java/jre/lib/amd64:/usr/local/java/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
java.specification.name = Java Platform API Specification
java.class.version = 50.0
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
flybus-admin.root = /project/flybus/flybus-admin/
os.version = 3.8.13-44.1.1.el6uek.x86_64
user.home = /root
catalina.useNaming = true
user.timezone = Asia/Shanghai
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = UTF-8
java.specification.version = 1.6
catalina.home = /usr/local/tomcat/flybus/tomcat-flybus-admin
java.class.path = /usr/local/tomcat/flybus/tomcat-flybus-admin/bin/bootstrap.jar
user.name = root
java.naming.factory.initial = org.apache.naming.java.javaURLContextFactory
package.definition = sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
java.vm.specification.version = 1.0
sun.java.command = org.apache.catalina.startup.Bootstrap start
java.home = /usr/local/java/jre
sun.arch.data.model = 64
user.language = zh
java.specification.vendor = Sun Microsystems Inc.
java.vm.info = mixed mode
java.version = 1.6.0_45
java.ext.dirs = /usr/local/java/jre/lib/ext:/usr/java/packages/lib/ext
jmagick.systemclassloader = false
sun.boot.class.path = /usr/local/java/jre/lib/resources.jar:/usr/local/java/jre/lib/rt.jar:/usr/local/java/jre/lib/sunrsasign.jar:/usr/local/java/jre/lib/jsse.jar:/usr/local/java/jre/lib/jce.jar:/usr/local/java/jre/lib/charsets.jar:/usr/local/java/jre/lib/modules/jdk.boot.jar:/usr/local/java/jre/classes
server.loader =
java.awt.headless = true
java.vendor = Sun Microsystems Inc.
catalina.base = /usr/local/tomcat/flybus/tomcat-flybus-admin
file.separator = /
java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
common.loader = ${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
sun.io.unicode.encoding = UnicodeLittle
sun.cpu.endian = little
package.access = sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
sun.cpu.isalist =
VM Flags:
-Djava.util.logging.config.file=/usr/local/tomcat/flybus/tomcat-flybus-admin/conf/logging.properties -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true -Djmagick.systemclassloader=false -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/tomcat/flybus/tomcat-flybus-admin/endorsed -Dcatalina.base=/usr/local/tomcat/flybus/tomcat-flybus-admin -Dcatalina.home=/usr/local/tomcat/flybus/tomcat-flybus-admin -Djava.io.tmpdir=/usr/local/tomcat/flybus/tomcat-flybus-admin/temp

上面的日志是一个使用tomcat服务器的JVM运行参数

2.第三方工具

TProfiler工具：TProfiler是一个可以在生产环境长期使用的性能分析工具.它同时支持剖析和采样两种方式,记录方法执行的时间和次数,生成方法热点对象创建热点以及线程状态分析等数据,为查找系统性能瓶颈提供数据支持。简单来说就是统计、分析最后记录协助用户根据产生的记录分析解决问题。

TProfiler工具：外国的TProfiler。

LoadRunner：是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。

附：

Java程序性能调优的过程

图1是一张Java程序性能调优的流程图，摘自由Charlie Hunt和Binu John所著的Java Performance。

转存失败重新上传取消

图1：Java程序性能调优的过程

JVM分布式模型

JVM分布式模型用于决定是在一个JVM还是多个JVM上执行Java程序。你可以根据其有效性、响应能力和可维护性来进行选择。当在多台服务器上运行JVM时，你也可以选择将多个JVM运行于一台服务器或者每台服务器运行一个JVM。例如，对于每台服务器，你可以运行一个使用8GB堆内存的JVM，也可以运行4个使用2GB的JVM。你理应根据处理器内核的个数还有程序的特性来决定这个数量。当优先考虑响应能力时，使用2GB的堆内存会优于8GB的，原因是这样能在更短的时间内完成Full GC。当然，8GB的堆内存可以降低Full GC的频率。如果你的程序使用了内部缓存，还可以通过增加缓存命中率来提高响应能力。综上所述，选择合适的模型需要考虑应用程序的特性，然后在各种模型中选定一个能够扬长避短的。

JVM架构

选择JVM其实就是决定使用32位还是64位的JVM。在相同的条件下，你最好用32位的。因为32位的JVM比64位性能更好。然而，32位 JVM最大支持的堆内存是4GB（无论在32位操作系统还是64位的上，实际可分配的大小都只有2-3GB）。如果需要更大的堆内存，还是用64位的 JVM比较合适。

表1：性能比较（数据来源）

测试基准	时间（秒）	系数
C++ Opt	23	1.0x
C++ Dbg	197	8.6x
Java 64-bit	134	5.8x
Java 32-bit	290	12.6x
Java 32-bit GC*	106	4.6x
Java 32-bit SPEC GC*	89	3.7x
Scala	82	3.6x
Scala low-level*	67	2.9x
Scala low-level GC*	58	2.5x
Go 6g	161	7.0x
Go Pro*	126	5.5x

下一步就是运行程序来测试它的性能。这个过程包括GC调优、改变操作系统设置和修改代码。对于这些工作，你可以使用系统监视工具或者性能分析工具。

注意：针对响应能力的调优和针对吞吐量的调优可能使用不同的方法。如果经常性地发生stop-the-word（串行GC暂时中断程序执行），程序的响应能力就会被降低。比如在高吞吐量时执行Full GC。不要忘记，在调优时往往有得有失。这样需要折衷处理的事情不仅发生在响应能力和吞吐量之间。例如使用更多的CPU资源来降低内存的使用，或者不得不忍受响应能力和吞吐量其中一个性能指标的下降。相反的情况同样可能发生，实际的调优应该根据各指标的优先级来执行。

上面图1中的流程展示了几乎可用于所有Java程序的性能调优过程，包括Swing应用。然而，对于我们公司NHN用于提供网络服务的服务器端程序来说，这个方法多少有些不合适。下面图2中的流程是根据图1修改而来，它更简单，也更适合NHN。

转存失败重新上传取消

图2：对HNH的Java程序的调优过程

其中，Select JVM表示尽可能使用32位的JVM，除非你需要用64位的JVM来维护一个数GB的缓存。

现在，跟随图2中的流程，你会了解到每一步具体的工作。

JVM参数

我会主要讲解如何为Web服务端程序设置合适的JVM参数。尽管不一定适合所有的案例，但是最好的GC算法是Concurrent Mark Sweep（CMS垃圾回收），特别是对于Web服务端程序。因为低延迟是非常重要的。当然，在使用CMS时，由于新生代空间（New Area）的分配，可能发生较长时间的stop-the-world现象，不过调整新生代空间的大小或者它和整个堆空间的比例可能解决这个问题。

指定新生代空间的大小和指定整个对堆内存的大小同样重要。你最好使用–XX:NewRatio来指定新生代和整个堆的大小比例，或者直接用–XX:NewSize来指定所需的新生代空间。这个配置是非常必要的，因为大部分对象都不会存活很久。在Web程序中，除了缓存数据，其他多数对象都只在HttpRequest到HttpResponse期间创建。这个时间几乎不会超过1秒，表示这些对象的存活时间也不会超过1秒。如果新生代空间不够大，对象会被转移到老年代空间，以便腾出地方给新对象使用。老年代空间（Old Area）垃圾回收的代价是比新生代空间大的多的，因此很需要设置一个充足的新生代空间。

然而，当新生代空间的大小超过一个特定的水平，程序的响应能力会被降低。因为新生代空间的垃圾回收过程，基本上是将数据从一个Survivor Area复制到另外一个（From Space和To Space）。另外，stop-the-world的现象在新生代空间和老年代空间执行垃圾回收时都会发生。如果新生代空间变大，那么Survivor Area的空间也会更大，于是每次复制的数据就更多。基于这样一种特性，我们应该通过指定不同操作系统中HotSpot JVM的NewRatio参数来分配合适大小的新生代空间。

表2：不同操作系统和配置下NewRatio的默认值

操作系统及参数	默认-XX:NewRatio
Sparc -server	2
Sparc -client	8
x86 -server	8
x86 -client	12

如果设置了NewRatio，那么整个堆空间的1/(NewRatio +1)就是新生代空间的大小。上表可以看出Sparc -server的NewRatio默认值很小，因为相比x86的操作系统，Sparc以前更多用于高端应用，这个值就是为它们设置的。但现在x86操作系统的性能有很大提升，使用它们作为服务器已经很普遍了。因此指定NewRatio为2或者3是更好的选择，就和Sparc -server上的配置一样。

另外，你还可以通过指定NewSize和MaxNewSize来代替NewRatio。那么新生代空间创建时的大小就是指定的NewSize，随后可以一直增长到MaxNewSize的值。Eden（新创建对象存放的区域）和Survivor Area两个区域会随比例增加。就和你为-Xms（译者注：原文是-Xs，应该是笔误）和-Xmx设置相同的值一样，将MaxSize和 MaxNewSize设置为相同的也是一个好选择。

如果同时指定了NewRatio和NewSize，你应该使用更大的那个。于是，当堆空间被创建时，你可以用过下面的表达式计算初始新生代空间的大小：

1	`min(MaxNewSize, max(NewSize, heap/(NewRatio+` `1` `)))`

无论如何，仅通过一次尝试就找到合适的堆空间和新生代空间大小是不可能的。根据我在NHN运行Web服务器的经验，建议使用下面的JVM参数来运行Java程序。监控在这些参数的条件下程序的性能表现之后，你就能够选择更合适的GC算法或者配置。

表3：推荐的JVM参数

类型	参数
运行模式	-sever
整个堆内存大小	为-Xms和-Xmx设置相同的值。
新生代空间大小	-XX:NewRatio: 2到4. -XX:NewSize=? –XX:MaxNewSize=?. 使用NewSize代替NewRatio也是可以的。
持久代空间大小	-XX:PermSize=256m -XX:MaxPermSize=256m. 设置一个在运行中不会出现问题的值即可，这个参数不影响性能。
GC日志	-Xloggc:$CATALINA_BASE/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps. 记录GC日志并不会特别地影响Java程序性能，推荐你尽可能记录日志。
GC算法	-XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75. 一般来说推荐使用这些配置，但是根据程序不同的特性，其他的也有可能更好。
发生OOM时创建堆内存转储文件	-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$CATALINA_BASE/logs
发生OOM后的操作	-XX:OnOutOfMemoryError=$CATALINA_HOME/bin/stop.sh 或 -XX:OnOutOfMemoryError=$CATALINA_HOME/bin/restart.sh. 记录内存转储文件后，为了管理的需要执行一个合适的操作。

测定程序的性能

为了得到程序的性能表现，需要以下这些信息：

系统吞吐量（TPS、OPS）：从整体概念上理解程序的性能。
每秒请求数（Request Per Second – RPS）：严格来说，RPS和单纯的响应能力是不同的，但是你可以把它理解为响应能力。通过这个指标，你能够了解到用户需要多长时间才能得到请求的结果。
RPS的标准差：如果可能的话，还有必要包括事件的RPS。一旦出现了偏差，你应该检查GC或者网络系统。

为了得到更准确的性能表现，你应该等到程序彻底启动完成后再进行测量，因为字节码随后会被HotSpot JIT编译为本地机器码。总体来说，需要在程序加载完指定功能后，用nGrinder等工具测试至少10分钟。

切实地调优

如果nGrinder测试的结果满足了预期，那么你不需要对程序进行性能调优。如果没有达到预期结果，你就应该执行调优来解决问题。接下来会通过实例讲解方法。

stop-the-world耗时过长

stop-the-world耗时过长可能是由于GC参数不合理或者代码实现不正确。你可以通过分析工具或堆内存转储文件（Heap dump）来定位问题，比如检查堆内存中对象的类型和数量。如果在其中找到了很多不必要的对象，那么最好去改进代码。如果没有发现创建对象的过程中有特别的问题，那么最好单纯地修改GC参数。

为了适当地调整GC参数，你需要获取一段足够长时间的GC日志，还必须知道哪些情况会导致长时间的stop-the-world。想了解更多关于如何选择合适的GC参数，可以阅读我同事的一篇博文：How to Monitor Java Garbage Collection。