一、项目背景下高并发系统中的采购接口。 对于wydzc，同时请求5W，而且每次请求20KB的对象(包括订单、用户、优惠券等对象数据)。
使用同时创建1MB对象的接口，可以模拟1万个并发请求级别生成大量对象的场景，如下例所示：
二、准备工作1.linux机器
我启动了一台Linux虚拟机，分配的内存为2G，处理器数量为2个，如下所示
2.apache AB压测工具
关于设置和使用方法，这里不太介绍。 请参考传送门
3.JVM参数
显示JVM进程号
jps监视JVM的minorGC和fullGC的时间、次数等信息
在jstat -gc进程编号5000 20 | awk '{print $13、$14、$15、$16、$17}'JVM中查看堆内存使用情况
jmap -heap工艺编号3，压力测量步骤首先开始项目
要通过jmap -heap进程号验证堆的默认分配，请执行以下操作：
最大堆内存为480m，初始化大小为32m。
伊甸园区： 103m
From区、To区：3~4m
OLd区： 18m
1.10 个并发用户/10万请求量(总)
使用ab命令进行测量
a B- C10-n 100003358127.0.0.1:8080/JVM/heap执行结束后查看结果
观察gc的状况
jst at-GC 9656500020|awk ' {打印$ 13，$14，$15，$16，$17 }
从两幅图的结果可以看出
用户的吞吐量为1426/秒左右的JVM服务器的平均请求处理时间0.7ms左右的JVM服务器产生2700次以上的YGC，需要15秒钟后45次FGC，2.3秒左右。 加起来GC是17秒2.100个并发用户/10万请求量(总)
步骤相同，以下直接说现象
用户吞吐量在1262/秒左右的JVM服务器的平均请求处理时间0.8ms左右的JVM服务器上发生了2700次以上的YGC，用了30秒； 还有56次FGC，3秒左右。 加起来GC是33秒3.1000个并发用户/10万请求量(总)
步骤相同，以下直接说现象
用户的吞吐量为1145/秒左右的JVM服务器的平均请求处理时间0.8ms左右的JVM服务器产生2700次以上的YGC，需要38秒钟后47次FGC，3秒左右。 如果总GC需要42秒4的时间，并且结果分析堆内存默认不配置堆内存的大小和比例，则JVM将采用默认配置，堆越小，minorGC次数越多
吞吐量
GC的吞吐量随着时间的增加而降低； fullGC越频繁，吞吐量越低，方案调整由上述结果可知，fullGC次数比minorGC次数少，但也影响性能。 因此，调整堆大小，将堆内存设置得稍大一些
在不设置方案SurvivorRatio启动命令的情况下调整大量空间
Java-jar-xms 1500 m-xmx 1500 mjvm-1.0-snapshot.jar这里是题外话。 通常，在设置堆大小时，将最大堆和最小堆参数设置为相同。 这样可以提前规划固定内存，避免动态扩展，并防止在jvm运行期间堆内存不足。
要通过jmap -heap进程号验证堆的默认分配，请执行以下操作：
最大堆内存为1.5G，初始化大小为1.5G
伊甸园区： 375m
From，To区： 62m
OLd区： 1000m
采用与此前相同的测量方法，结果如下1.10 个并发用户/10万请求量(总)
用户吞吐量在1205/秒左右的JVM服务器的平均请求处理时间0.83ms左右的JVM服务器上发生ygc 800次，需要33秒，另外FGC次，需要1秒左右，加起来GC为34秒http://www.Sina .
用户吞吐量在989/秒左右的JVM服务器的平均请求处理时间1.01ms左右的JVM服务器上发生800次YGC，需要46秒，还有8次FGC，需要6秒左右，加起来GC需要52秒http://www.Sina
用户吞吐量在749/秒左右的JVM服务器的平均请求处理时间1.3ms左右的JVM服务器上发生800次YGC，需要66秒，还有8次FGC，需要9秒左右，加起来GC需要75秒左右。方案2 :调整大量空间
p>启动命令改为 java -jar -Xms1500m -Xmx1500m -Xmn1000m -XX:SurvivorRatio=8 jvm-1.0-SNAPSHOT.jar通过jmap -heap 进程号查看堆默认分配情况为：
最大堆内存为 1.5G，初始化大小为 1.5G
Eden 区 800m
From、To 100M
OLd =500M
用与之前同样的压测方式，结果如下
1.10 个并发用户/10万请求量(总)
用户的吞吐量大于在 1780/每秒左右JVM 服务器平均请求处理时间 0.56ms 左右JVM 服务器发生了 400 次 YGC,耗时 5.8 秒 ，还有 2 次 FGC,0.1 秒左右，加在一起 GC 耗时 6 秒2.100个并发用户/10万请求量(总)
用户的吞吐量大于在 1927/每秒左右JVM 服务器平均请求处理时间 0.51ms 左右JVM 服务器发生了 400 多次 YGC,耗时 11 秒 ，没有 FGC，加在一起 GC 耗时 11 秒3.1000个并发用户/10万请求量(总)
用户的吞吐量大于在 1657/每秒左右JVM 服务器平均请求处理时间 0.6ms 左右JVM 服务器发生了 400 多次 YGC,耗时 14 秒 ，还 1 次 FGC,3 秒左右，加在一起 GC 耗时 17 秒 六、结果总结和分析在方案一中，虽然调大了堆空间，但是吞吐量和GC耗时的结果相比没有调大时，反而还差了点；
方案二不仅调大了堆空间，还设置了eden和survivor的比例，在所有结果无疑是最好的。
为什么会出现这个情况呢？不管是方案一还是方案二，可以确定的是业务场景里每个对象存活对象时间都是固定的。
而在方案一中，堆空间是增大了，但eden区域并没有很大，因此eden区域还是很快被填满，并开始minorGC。minorGC时大量对象可能还是存活的，因此GC时间为：扫描整个堆空间+复制存活对象。复制存活对象会采用复制算法，是一个很耗时的操作；同时，由于堆空间相比没有任何调整前还大，因此扫描整个堆空间的时间也更长，导致方案一的GC耗时和吞吐量也更低。
在方案二中，eden区域很大，因此出现minorGC的频率相比方案一更低。同时开始minorGC时，大量对象可能都已过了存活时间，因此GC时间为：只扫描整个堆空间，而没有复制存活对象的时间。虽然扫描整个堆空间的时间也更长，但是相比复制的成本，可以忽略。
所以方案二由于方案一。